10979D ENU TrainerHandbook

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
10979D
Microsoft Azure Fundamentals
MCT USE ONLY. STUDENT USE PROHIBITED
ii Microsoft Azure Fundamentals
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: 10979D
Part Number: X21-56543
Released: 09/2017
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

Microsoft Azure Fundamentals xi
xii Microsoft Azure Fundamentals
Acknowledgments
Microsoft Learning would like to acknowledge and thank the following for their contributions towards
developing this title. 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 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 Senior Program Manager for the Azure Customer Advisory Group (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,
Microsoft Management Summit (MMS), and PASS Summit. Telmo is very active in the Microsoft Certified
Trainer (MCT) community, being one of the first MCT Regional Leads.
Microsoft Azure Fundamentals xiii
Contents
Module 1: Getting started with Microsoft Azure
Module Overview 1-1
Lesson 1: What is cloud computing? 1-2
Lesson 2: What is Azure? 1-7
Lesson 3: Managing Azure 1-15

Lesson 4: Subscription management, support, and billing 1-20
Lab: Using the Azure portals 1-25
Module Review and Takeaways 1-27
Module 2: Microsoft Azure management tools

Module Overview 2-1
Lesson 1: What is Azure PowerShell? 2-2
Lesson 2: Azure SDK and Azure CLI 2-8
Lab: Using Microsoft Azure management tools 2-13
Module 3: Virtual machines in Microsoft Azure

Module Overview 3-1
Lesson 1: Creating and configuring VMs 3-2
Lesson 2: Configuring disks 3-15
Lab: Creating a VM in Azure 3-22

Module 4: Web Apps and cloud services

Module Overview 4-1
Lesson 1: Creating and configuring web apps 4-2
Lesson 2: Deploying and monitoring web apps 4-10
Lesson 3: Creating and deploying PaaS cloud services 4-18
Lab: Web Apps and cloud services 4-23
Module 5: Creating and configuring virtual networks

Module Overview 5-1
Lesson 1: Getting started with virtual networks 5-2
Lesson 2: Configuring Azure networking 5-7
Lesson 3: Getting started with Azure Load Balancer 5-11
Lab: Create and configure virtual networks 5-14

xiv Microsoft Azure Fundamentals
Module 6: Cloud storage

Module Overview 6-1
Lesson 1: Understanding cloud storage 6-2
Lesson 2: Create and manage storage 6-9
Lab: Configure Azure Storage 6-15
Module 7: Microsoft Azure databases

Module Overview 7-1
Lesson 1: Understanding options for relational database deployments 7-2
Lesson 2: Creating and connecting to Azure SQL databases 7-6

Lab: Creating a SQL Database in Azure 7-11
Module 8: Creating and managing Azure AD

Module Overview 8-1
Lesson 1: Overview of Azure AD 8-2
Lesson 2: Manage Azure AD authentication 8-12
Lab: Create and manage Azure Active Directory tenants 8-15

About This Course xv
About This Course

This section provides a brief description of your course, including audience, suggested prerequisites, and
course objectives.
Course Description
This course provides the underlying knowledge required by all individuals who will be evaluating
Microsoft Azure, whether they are administrators, developers, or database administrators. This course
also provides the prerequisite knowledge for students wanting to attend Course 20532: Developing
Microsoft Azure Solutions, or Course 20533: Implementing Microsoft Azure Infrastructure Solutions.
This course will introduce students to the principles of cloud computing. Students will become familiar
with how Microsoft Azure implements these principles. In addition, this course will explain how to
implement the core Azure infrastructure, consisting of virtual networks and storage. With this foundation,
students will learn how to create the most common Azure services, including Azure Virtual Machines,
Web Apps, and Azure SQL Database (SQL Database). The course will conclude by describing the features
of Azure Active Directory (Azure AD) and methods of integrating it with on-premises Active Directory
Domain Services (AD DS).
Audience
The intended audience of this course is individuals who want to evaluate deploying, configuring, and
administering services and VMs by using Azure. This includes:
 Developers who want to evaluate the process for creating Azure solutions.
 Windows Server administrators who want to evaluate migrating on-premises Active Directory roles
and services to the cloud.
 Information Technology (IT) professionals who want to evaluate the use of Azure to host websites
and mobile app back-end services.
 Database administrators who want to evaluate the use of Azure to host SQL databases.
Student Prerequisites
Before attending this course, students must have a background in IT. In addition to their professional
experience, students who attend this training should have the following technical knowledge:
 Understanding of how to deploy websites.
 A basic understanding of virtualization.
 A basic understanding of Active Directory concepts, including domains, users, and domain
controllers.
 A basic understanding of database concepts, including tables and simple queries.
Course Objectives
After completing this course, students will be able to:
 Describe cloud computing, Azure, and Azure subscriptions.
 Use Azure PowerShell, the Azure Software Development Kit (SDK), and the Azure command-line
interface (CLI) to manage Azure subscriptions.
 Create and configure virtual machines in Azure, and manage their disks.
 Create, configure, and monitor web apps in Azure and deploy Azure platform as a service (PaaS)
cloud services.
xvi About This Course
 Create and configure Azure virtual networks.
 Create, manage, and configure cloud storage in Azure.
 Use Azure SQL Database to create, configure, and manage SQL databases.
 Create and manage Azure AD.
Course Outline
The course outline is as follows:
 Module 1, “Getting started with Microsoft Azure” introduces students to cloud services and the
various Azure services. It describes how to use the Azure portal to access and manage Azure services,
and to manage Azure subscription and billing.
 Module 2, “Microsoft Azure management tools” explains Azure PowerShell and its use in managing
Azure subscriptions. It also describes how to use the Azure SDK and the Azure CLI to manage Azure
subscriptions.
 Module 3, “Virtual machines in Microsoft Azure” explains how to create and configure virtual
machines in Azure and how to manage disks for virtual machines.
 Module 4, “Web Apps and cloud services” explains how to create, configure, and monitor web apps
in Azure. It also describes how to create and deploy Azure PaaS cloud services.
 Module 5, “Creating and configuring virtual networks” explains how to create and implement Azure
networks and how to use their components to enhance the resiliency and availability of virtual
machines.
 Module 6, “Cloud storage” explains the features and benefits of cloud storage. It also explains how
to create, manage, and configure cloud storage in Azure.
 Module 7, “Microsoft Azure databases” explains the options available for storing relational data in
Azure. It also explains how to use SQL Database to create, configure, and manage SQL databases in
Azure.
 Module 8, “Creating and managing Azure AD” explains how to create users, domains, and
directories in Azure AD, integrate applications with Azure AD, and use Multi-Factor Authentication.
About This Course xvii
Course Materials
The following materials are included with your kit:
 Course Handbook: 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.
 Lessons: guide you through the learning objectives, and provide the key points that are critical to
the success of the in-class learning experience.
 Labs: provide a real-world, hands-on platform for you to apply the knowledge and skills learned in
the module.
 Module Reviews and Takeaways: provide on-the-job reference material to boost knowledge and
skills retention.
 Lab Answer Keys: 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: searchable, easy-to-browse digital content with
integrated premium online resources that supplement the Course Handbook.
 Modules: include companion content, such as questions and answers, detailed demonstration steps,
and additional reading links for each lesson. Additionally, modules 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: include well-categorized additional resources that give you immediate access to the
most current premium content on TechNet, MSDN, or Microsoft Press.
 Course evaluation: at the end of the course, you will have the opportunity to complete an online
evaluation to provide 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.
xviii About This Course
Virtual Machine Environment

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

In this course, you will use a Windows 10 client computer running on Hyper-V to perform the labs.
Software Configuration
The MIA-CL1 virtual machine has the following software installed:
 Internet connectivity
 Windows 10 Enterprise operating system
 Microsoft Visual Studio Community 2017
 Azure PowerShell 4.2.0
 Azure CLI
 Microsoft SQL Server 2017 Management Studio
This course requires every student to register at http://aka.ms/mocazurepass at least two days before the
start of the course.
Course Files
The files associated with the labs in this course are located in the install_folder\Labfiles\ModXX folder on
the student computers (where XX is the number of the associated module).
Classroom Setup
Each classroom computer will have the same virtual machines configured in the same way.
The following table shows the role of each virtual machine that this course uses.
Virtual machine Role
10979D-MIA-CL1 Windows 10 computer used in all the labs
MT17B-WS2016-NAT Provides gateway access to the Internet
Azure
This course contains labs which require access to Azure. You will receive a Microsoft Learning Azure Pass
to facilitate access to Microsoft Azure. Your Microsoft Certified Trainer (MCT) will provide details about
how to acquire, set up, and configure your Microsoft Azure access.
You should be aware of some general best practices for using the Microsoft Learning Azure Pass:
 Check the dollar balance of your Azure Pass within Microsoft Azure once you have set up your
subscription, and be aware of how much you are consuming as you proceed through the labs.
 Do not allow Azure components to run overnight or for extended periods unless you need to do so,
as this will use up the pass dollar amount unnecessarily.
 Remove any Azure-created components or services such as storage, virtual machines, and cloud
services after you finish your lab to help minimize cost usage and extend the life of your Microsoft
Learning Azure Pass.
About This Course xix
Note: You can use your own full or trial Azure subscription if you wish. However, you
should note that the labs have not been tested with all subscription types and, while unlikely,
some variation might exist due to subscription limitations. Also, be aware that the scripts used in
the labs will delete any existing services or components present in Azure under the subscription
that you use.
Course Hardware Level

To ensure a satisfactory student experience, Microsoft Learning requires a minimum equipment
configuration for trainer and student computers in all Microsoft Learning Partner classrooms in which
Official Microsoft Learning Product courseware is taught:
 The minimum equipment configuration for this course is hardware level 7 with 16 gigabytes (GB) of
random access memory (RAM).
1-1
Module 1
Getting started with Microsoft Azure
Contents:
Module Overview 1-1
Lesson 1: What is cloud computing? 1-2
Lesson 2: What is Azure? 1-7
Lesson 3: Managing Azure 1-15

Lesson 4: Subscription management, support, and billing 1-20
Lab: Using the Azure portals 1-25
Module Overview
As organizations move their information technology (IT) workloads to the cloud, it becomes imperative
that IT professionals and developers understand the principles that form the basis for cloud solutions,
and learn how to deploy and manage cloud applications, services, and infrastructure.
This module starts with a general overview of cloud computing, and then it focuses on Azure and its
services that organizations use most commonly. It also introduces the Azure portal, which serves as the
primary graphical user interface (GUI) for managing these services. The module concludes with a
description of the main characteristics of Azure subscriptions, and Azure billing and support options.
Objectives
After completing this module, you will be able to:
 Describe cloud computing.
 Describe Azure and its various services.
 Manage Azure services from the Azure portal.

 Manage your Azure subscription and billing.
1-2 Getting started with Microsoft Azure
Lesson 1
What is cloud computing?
Cloud computing plays an increasingly important role in IT infrastructure. Therefore, as an IT professional,
you must be aware of fundamental cloud principles and techniques. There are three main cloud-
computing models: public, private, and hybrid. Each of these models provides an equivalent range of
services, but each implements and delivers the services in a different manner. As part of your journey to
the cloud, you need to become aware of these differences and decide which model best suits your
needs.
This lesson introduces cloud computing, and describes the considerations for implementing cloud-based
services.
Lesson Objectives
After completing this lesson, you will be able to:
 Describe key principles of cloud computing.
 Describe the characteristics of public, private, and hybrid cloud-computing models.
 Identify the most common types of cloud services.

 Identify suitable uses for cloud services.
Overview of cloud computing

Cloud computing, or the cloud, is a leading IT
trend. However, its definition is ambiguous, and
some cloud terminology is confusing. Trying to
define the cloud in purely technical terms is
difficult, but it is best to think of it as an abstract
concept that encapsulates techniques that
provide computing services from a shared
resource pool.
Most cloud solutions are built on virtualization
technology, which abstracts physical hardware as
a layer of virtualized resources for processing,
memory, storage, and networking. Many cloud
solutions add further abstraction layers to define specific services that you can provision and use.
However, regardless of the specific technologies that organizations use to implement cloud-computing
solutions, the National Institute of Standards and Technology has identified that they exhibit the
following five common characteristics:
 On-demand self-service. You provision cloud services on as-needed basis, and they require that the
consumer perform minimal infrastructure configuration. As a result, users of cloud services can
quickly set up the resources that they want, typically without having to involve IT specialists.
 Broad network access. Consumers usually access cloud services over a network connection, relying
on 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.
Microsoft Azure Fundamentals 1-3
 Rapid elasticity. Cloud services can scale dynamically to obtain additional resources from the pool as
workloads increase, and to release resources automatically when the need for them no longer exists.
 Measured service. Cloud services generally include metering capabilities, which allows 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 offers several advantages in comparison to traditional, on-premises, datacenter-based
computing. Cloud computing offers:
 A managed datacenter. Your service provider can manage your datacenter, which means you do not
have to manage your own IT infrastructure. Cloud computing also enables you to access computing
services, regardless 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 service
delivery rather than infrastructure.
 Lower operational costs. Cloud computing provides pooled resources, elasticity, and virtualization
technology. These factors help you minimize issues such as inefficient resource usage, inconsistent
availability, and high operational costs. You typically pay only for the services that you use; which can
translate into substantial savings in operational costs for most organizations.
 Improved flexibility and speed. The ability to rapidly scale your workloads, both horizontally and
vertically, and deploy new solutions without having to consider infrastructure constraints allows you
to address changing business needs efficiently.
Cloud-computing models
Cloud computing uses three main
implementation models:
 Private cloud. Organizations can own and

manage their computing resources in the
form of private clouds, which offer benefits
similar to those of public clouds. However,
their design is for a single organization’s use,
and the organization manages and maintains
the private cloud’s infrastructure in its own
datacenter. A key benefit of this approach is
that the organization has complete control
over the cloud infrastructure and the services
that it provides. However, as a result, the organization also must manage overheads and costs
associated with the datacenter and infrastructure ownership.
 Public cloud. Public clouds are infrastructure, platform, or application services that a cloud service
provider delivers for access and consumption by multiple organizations. When an organization
utilizes public-cloud services, the organization is not responsible for the management overhead that
the private-cloud model requires. However, this also means that the organization has limited control
over the infrastructure and services, which the cloud service provider manages. Additionally, the
public cloud hosts the infrastructure and services for multiple organizations, which introduces data-
sovereignty considerations that pertain to multitenancy.
 Hybrid cloud. In a hybrid cloud, a technology binds two separate clouds (public and private) together
to combine and complement the benefits that each delivers. This allows you to decide which
elements of your services and infrastructure you want to host privately and which you want to host
in the public cloud. Many organizations use a hybrid model by extending their existing on-premises
private-cloud implementation to the cloud.
Microsoft cloud services provide technology and applications across all of these cloud-computing
models. Some examples of Microsoft cloud services are:
 Microsoft public-cloud services:
o Azure. Azure is a public-cloud environment that offers platform as a service (PaaS), software as a
service (SaaS), and infrastructure as a service (IaaS). Customers can subscribe to Azure and use,
customize, or develop a wide range of services and applications. Other Microsoft cloud services
leverage Azure to deliver some of their SaaS applications.
o Office 365. Office 365 provides online versions of the Microsoft Office applications and online
business-collaboration tools.
o Microsoft Dynamics Customer relationship management (CRM) Online. Dynamics CRM Online is
the cloud-based version of the on-premises Microsoft Dynamics CRM.
 Microsoft private cloud:

o Hyper-V in Windows Server integrates with System Center to create the foundation for building
private clouds. When you implement these products as a combined solution, you can deliver
IaaS-based services in your on-premises environment.
 Microsoft hybrid cloud:
o Microsoft currently provides several solutions that support the hybrid-cloud model, by enabling
you to:
 Manage, monitor, and move virtual machines across different clouds.
 Implement disaster-recovery solutions with Azure as the recovery site.
 Deploy cloud-based solutions that are comprised of components that on-premises
datacenters are hosting.
 Leverage a combination of on-premises directory services with Azure Active Directory and
other cloud-based identity providers to facilitate authentication and authorization.
o The introduction of Azure Stack, which was in Technical Preview during this course’s creation,
builds on the networking and storage virtualization capabilities of Windows Server 2016. It
promises to deliver the first hybrid cloud platform that closely integrates with the public-cloud
services that Microsoft offers. The primary benefits of this integration include:
 Consistent development methodology, which improves productivity and enables you to
leverage existing Azure services to build Azure Stack-based solutions.
 Consistent management and user experience as well as the matching set of automation
tools, reducing administrative overhead.
 Increased flexibility in designing solutions that are not suitable for fully public cloud-based
deployments due to such constraints as government regulations, network latency, or
customizability.
Types of cloud services

Cloud services generally fall into one of three
categories, according to their management
capabilities:
 SaaS
 PaaS
 IaaS
SaaS
SaaS offerings deliver applications as cloud-based
services. Users can subscribe to these services and
use the corresponding applications, usually
through a web browser or by installing a client-side app. The most common examples of Microsoft SaaS
services include Microsoft Office 365, Skype for Business Online, OneDrive, and Microsoft Dynamics CRM
Online. The primary advantage of SaaS services is that they provide immediate access to applications
without users having to install and maintain them. Customers do not have to worry about issues such as
insufficient patch levels or lack of compliance, because the service provider handles all corresponding
maintenance tasks.
PaaS
PaaS offerings consist of cloud-based services that provide resources that developers can leverage to
design and implement their own solutions. Typically, PaaS consists of fundamental operating-system
capabilities, including storage and computing, and functional services that assist with managing
application lifecycle. PaaS offerings usually incorporate application programming interfaces (APIs), as well
as configuration and management interfaces. The most common examples of Microsoft PaaS services
include Azure SQL Database or Azure App Service.
IaaS
IaaS offerings provide virtualized server and network-infrastructure components that users can provision
and decommission easily when necessary. Typically, these components’ characteristics map relatively
closely to the characteristics of their on-premises counterparts. For example, designing a virtual network
in Azure is very similar to designing an on-premises network infrastructure. Similarly, a virtual machine
that is running in Azure resembles, in many ways, a virtual machine that you host in your on-premises
datacenter. As a result, IaaS offerings typically provide a straightforward migration path for moving
existing on-premises applications to the cloud.
Discussion: How will cloud computing benefit your organization?

Consider how the various cloud-computing
scenarios might benefit your organization. Be
prepared to discuss this with the class.
Lesson 2
What is Azure?
Azure is a public-cloud offering from Microsoft that provides a wide range of IaaS, PaaS, and SaaS
services from globally distributed datacenters. This lesson provides an overview of the Azure
infrastructure and its services, and it also introduces two management models that are available if you
provision these services.
Lesson Objectives
 Describe Azure.
 Describe the available Azure services.
 Identify Azure management models.
Overview of Azure
Azure is a collection of services that provide
computing and storage resources. Customers can
use these resources to build and operate their
applications, rather than relying exclusively on
their on-premises IT infrastructure. A global
network of datacenters host Azure services. In
general, Azure offers a 99.9 percent service level
agreement (SLA), with respect to availability, for
the majority of its services. However, specifics of
the SLA depend on such factors as pricing tier
and redundancy level in the Azure services’
design.
Azure services allow you to:
 Deploy and operate cloud-based applications by using a wide range of commonly used tools and
frameworks.
 Host workloads in the cloud, by relying on Azure PaaS services and capitalizing on the IaaS
infrastructure. The latter includes virtual machines and virtual networks.
 Integrate cloud services with an on-premises infrastructure.
When you create a new Azure service, you typically need to 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 that service’s users. It is usually best to place the service as close to them as possible. Some services
allow you to serve content from more than one Azure region, which means you can serve content to a
truly global audience, while helping to ensure that a localized response provides your users with the best
possible response times.
At the time of this course’s creation, the list of existing and newly announced Azure regions includes the
following:
 Americas
o East United States (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 Arizona
o US Gov Virginia
o US Gov Iowa
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 West
o UK South
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 West India
o Japan East
o Japan West
o Korea Central
o Korea South
 Africa
o South Africa West
o South Africa North
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
Datacenter placement follows the principle of pairing, and each datacenter has its counterpart in the
same geographical area. The only 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.
This often is required to comply with regulatory, compliance, and data-sovereignty rules that
governments and regional organizations impose. Additionally, Microsoft’s Azure datacenter disaster-
recovery and maintenance procedures consider 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
take into account datacenter pairing.
The design of the datacenters minimizes power usage for maximum efficiency, relying on a modular
design to streamline implementation and maintenance. Server clusters in each datacenter contain
multiple racks of servers. The Fabric Controller distributed service manages provisioning, dynamic scaling,
and hardware fault management for the virtual servers that host cloud services on the cluster’s physical
servers.
Overview of 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 Virtual Machine Scale Sets. Provision

highly available and automatically scalable groups of Windows and Linux virtual machines.
o Cloud Services. Define multi-tier PaaS cloud services that you can deploy and manage on Azure.
o Batch. Run high volume, large-scale parallel and high-performance computing apps on a scaled
and managed set of virtual machines.
o 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 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 Notification Hub. Implement push notifications for apps and services.
 Data & Storage, which provides the following options:
o Azure CosmosDB. Implement a globally distributed, schema-agnostic, multi-model data store.

o Azure SQL Database. Implement relational databases for your apps without having to provision
and maintain a database server.
o SQL Data Warehouse. Provision data warehouse as a service.

o Redis Cache. Implement high-performance caching solutions for your apps.
o Storage. Store data in files, binary large objects (BLOBs), tables, and queues.
o StorSimple. Provision a multi-tier storage solution that provides cloud hosting for on-premises
data.
o 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 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 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 Machine Learning. Run predictive analytics and forecasting based on existing data sets.
o Stream Analytics. Set up real-time data analysis from a variety of sources.
o Data Factory. Create data pipelines by using data storage, data-processing services, and data
movement.
o Data Catalog. Implement the registration and discovery of enterprise data sources.
 Internet of Things (IoT), which provides the following options:
o IoT Suite and Azure IoT Hub. Process massive amounts of telemetry data that connected devices
and apps generate.
o Event Hubs. Collect telemetry data from connected devices and apps.
o Stream Analytics. Process real-time data from connected devices and apps.
 Networking, which provides the following options:
o Virtual Network. Connect and segment the cloud infrastructure components.
o ExpressRoute. Extend your on-premises network to Azure and Microsoft cloud services through
a dedicated private connection.
o Traffic Manager. Configure global load balancing, based on Domain Name System (DNS).
o Azure Load Balancer. Implement an automatically scalable transport and network-layer load
balancing.
o Application Gateway. Build an application-layer load balancing, with support for such features as
Secure Sockets Layer (SSL) offloading, cookie affinity, or URL-based routing.
o Azure DNS. Host and manage your DNS domains and records for use with Azure services.
o VPN Gateway. Create network connections between Azure and on-premises networks over the
internet.
o Application Gateway. Build a scalable application-level load balancing.
 Media & Azure Content Delivery Network, which provides the following options:
o Media Services. Deliver multimedia content, such as video and audio.
o Content Delivery Network. Speed up delivery of web content to users throughout the world.
 Hybrid Integration, which provides the following options:
o BizTalk Services. Build integrated business-orchestration solutions that integrate enterprise apps
with cloud services.
o Service Bus. Connect apps across on-premises and cloud environments.
o Backup. Provide retention and recovery by backing up your on-premises and cloud-based
Windows and Linux systems to Azure.
o 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 AD DS with the cloud-based Identity and
Access solution, and provide single-sign on (SSO) capabilities for cloud-based and on-premises
applications and services.
o 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 Key Vault. Store and manage cryptographic artifacts, such as keys and passwords.
 Developer Services, which provides the following options:
o Visual Studio 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 Automation. Automate long-running, frequently repeating, and time-consuming tasks.
o Operational Insights. Build operational intelligence by using data that is collected from your
cloud and on-premises environments.
o Security Center. Monitor and manage control of and access to Azure resources.
o Network Watcher. Monitor and diagnose networking functionality and performance.
Note: Microsoft is improving and enhancing Azure continuously, and adds new services
regularly.
Additional Reading: For a full list of services that are currently available in Azure, refer to:
the “Popular products” section at: http://aka.ms/Qe9skc
Azure management models

Historically, the Service Management
programming model was the primary method
for managing Azure services. The Service
Management model dictated how you created
and managed resources, and the properties and
methods that those services supported. This, in
turn, affected their behavior and the actions that
you could apply to them. These properties and
actions were exposed via graphical and
programmatic interfaces. The GUI was a web
portal, while the programmatic interface was
accessible via programming and scripting
languages, including Windows PowerShell.
As Microsoft cloud technologies have evolved and matured, it became evident that the original
management 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.
A resource group provides a management and security boundary for resources that are its members.
Resource group membership typically is based on its resources’ lifecycles, although your choice of criteria
for grouping resources is entirely arbitrary. Essentially, rather than administering and maintaining them
individually, you can manage them as a group. Additionally, resource groups allow you to obtain
estimated costs, auditing events, and utilization data for the resources within those groups.
Note: Every resource that you create exists in one, and only one, resource group. This also
applies to services that you deploy by using Service Management. However, in this case, you
cannot specify the target resource group to use.
Azure Resource Manager also fully supports a role-based access control (RBAC). This mechanism relies
on predefined and custom-defined roles to grant users and groups that reside in Azure Active Directory
with the necessary permissions to conduct role-specific actions on a subscription, resource group, or
resource level. Tagging is another benefit of the new management model, and it involves assigning
arbitrary labels to resources and resource groups. You can utilize this to document your cloud
environment and, for example, specify a resource’s ownership, and then identify that resource as a part
of your production, test, or development environment. Additionally, billing data includes tags, which
allows you to identify cost associated with tagged resources.
Note: When assigning permissions via RBAC, you have to choose users and groups from
the Azure Active Directory tenant that is associated with your subscription. When you create a
new subscription by using a Microsoft account, you will provision a new Azure Active Directory
tenant automatically, labeled Default Directory, in your subscription. This tenant also is
associated with your Azure subscription automatically. However, you can change this association
to use the same Azure Active Directory tenant across multiple subscriptions.
The group-based approach also ties to a new deployment methodology that Azure Resource Manager
introduced, and which is based on deployment templates. A template is a JSON-formatted file that
defines a resource collection that you intend to implement in the same resource group. The resulting
deployment populates the target resource group, according to the template’s content.
While the traditional deployment methods relying on the GUI, or scripting and programming languages,
are still available, templates offer additional benefits. Similar to scripts, they facilitate deployment of
more complex solutions in an automated manner. However, they do not dictate the method to provision
these solutions, but do define their desired end state. Therefore, they utilize intelligence that is built into
the Azure platform to deploy individual resources in the most optimal way, which results in optimized
deployment speed and minimizes the potential for errors.
Resource groups and deployment templates are ideal if you need to build development, test, quality
assurance, or production environments quickly. For example, developers can delete their environment
quickly by removing a resource group, and then can create a new environment by redeploying a
template.
Note: With the introduction of Azure Resource Manager, the Service Management model
was rebranded as classic. You frequently will see instances of this term, which references Azure
services that were deployed by using Service Management.
Check Your Knowledge

Question
Which of the following items did Azure Resource Manager introduce?
Select the correct answer.
Tags
Template-based deployment
Role-based access control (RBAC)
An Azure Web portal
Windows PowerShell-based management of Azure services

Lesson 3
Managing Azure
Azure provides web-based portals in which you can provision and manage your organization’s Azure
subscriptions, services, and resources. These portals provide a friendly, intuitive environment for
interacting with Azure. In this lesson, you will learn how to navigate these portals and use their basic
features.
Lesson Objectives
 Describe the Azure classic portal.
 Describe the Azure portal.
 Explain how to use the Azure portals.
 Describe additional Azure management tools that are not web-based.
The Azure portal

The Azure portal at https://portal.azure.com is the
primary user interface (UI) for provisioning and
managing Azure resources and services. It is a
web application, and it requires that you sign in
by using one of two types of accounts:
 Microsoft account which takes the form of

<user>@outlook.com, or
<user>@hotmail.com or similar.
 Work or School Account, which takes the

form <user>@contoso.onmicrosoft.com, or
<user>@contoso.com.
Note: Work or School account is a new term that replaces the term Organizational account,
however, you might encounter both when working with Azure portals and reading Azure
documentation.
Work or School accounts are different from Microsoft accounts, because they are sourced from Azure
Active Directory tenant that is associated with the subscription. As a result, you have more options for
managing these types of accounts. For example, you can configure them with multi-factor
authentication, which forces users to provide additional information to verify their identities.
Note: While the majority of management tasks are available in the Azure portal at
https://portal.azure.com, a few services require you to use other portals. However, even in these
cases, you should consider the Azure portal as your primary reference point, because you can
find entries for every Azure service in the Azure portal. In case of those few services that require
use of other portals, if you click their entries in the Azure portal, the portal redirects you
automatically to the relevant Web interface.
The Azure portal visual elements

The Azure portal contains the following primary UI elements:
 Dashboard. The dashboard is a customizable home page that serves as the starting point of your
interaction with the Azure environment. You can pin items that you use regularly to your dashboard,
thereby making it easier to navigate to them. By default, the dashboard includes several precreated
tiles, including the global Azure Service health, which is a shortcut to the list of all resources that you
have provisioned, as well as the Marketplace and Help + support tiles. You also can create multiple
dashboards, switch between them depending on your preferences, and share them with others.
 Blades. Blades are scrollable panes in which you can view and configure details of an item that you
select. As you select items in the current blade, new blades open on the right side of it, so you can
navigate through several blades. This enables you to view the details of resources that the currently
selected item consists of, or with which it is associated. 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
search for them based on the values of tags that you assigned to them previously.
Other navigational features that enhance user experience include the:

 Microsoft Azure label in the upper-left corner, which allows you to display the dashboard quickly.
 Menu button, which is underneath the dashboard, and which controls the hub menu’s size.
 Breadcrumb bar, which is to the dashboard’s right, and which simplifies returning 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.
What management modules does the Azure portal support?

The Azure portal supports both Service Management and Azure Resource Manager management
models, and typically indicates this by interface references to the “classic” and “Resource Manager”
terms. For example, you will see this textual distinction when looking at the Hub menu’s options, which
might include “Virtual machines” and “Virtual machines (classic)”. Additionally, you will see it when you
create a virtual machine, and you have to choose between the “Resource manager” and “classic” virtual
machine types.
The Azure classic portal

The Azure classic portal, which you can access at
https://manage.windowsazure.com, is the legacy
web interface that you can use to access your
Azure subscription’s services. This interface differs
significantly from the Azure portal. Furthermore,
you cannot customize it, and it does not support
newer features, including those that are
applicable to the Azure Resource Manager model.
The visual elements of the Azure classic

portal
The Azure classic portal consists of several
individual pages that represent a number of
Service Management services. However, there are two exceptions to having an individual page
representing a service. These include the all items page that displays all Service Management services
provisioned in your subscriptions and the Settings page, in which you can configure subscription-wide
settings.
You can click the New button in the portal’s lower-left corner to provision a new instance of a service.
Similar to the Azure portal, service provisioning occurs asynchronously. You can use an indicator at the
page’s bottom to view a list of completed and in-process tasks.
The all items page and each service-specific page list your provisioned services. The list shows the name,
status, and service-specific settings for each service. You can click a service name in the list to view that
server instance’s dashboard, and multiple tabbed subpages allow you to view and configure service-
specific settings. In most cases, you make changes to a service by using the command bar, at the bottom
of each subpage. It includes context-specific icons.
The Azure classic portal and support for management models

The Azure classic portal supports only the Service Management model. You will not find any references
to resource groups, and you will not be able to manage or view services or resources that you deploy in
your subscription by using Azure Resource Manager.
Demonstration: Navigating the Azure portals

In this demonstration, you will see how to:
 Navigate the Azure portal.
 Navigate the Azure classic portal.

Client tools
The Azure portals provide an easy-to-use GUI
from which you can manage your Azure
subscriptions and services. However, due to their
interactive nature, they are not suitable for
automation or for streamlining routine, repetitive,
and potentially error-prone tasks. If you want to
minimize your administrative overhead, you
should utilize scripts or programs by using
Windows PowerShell, the Azure Command-Line
Interface (CLI), or Microsoft Visual Studio. A
fourth option, Azure Cloud Shell, combines the
benefits of the Azure portal GUI and the
automation capability of command-line tools.
Using Windows PowerShell with Azure PowerShell modules

Windows PowerShell provides a scripting platform from which you can manage a wide range of
infrastructure elements, including Azure subscriptions and their components. You can do this from a
computer that is running the Windows, Linux, or Mac OS X operating systems. Windows PowerShell’s
versatility is the result of its extensibility, which capitalizes on PowerShell modules that contain
encapsulated code in PowerShell cmdlets. After you import these modules into your operating system,
you can start using these cmdlets.
Azure PowerShell module is the primary PowerShell library for managing Azure services.
Note: You will learn more about Azure PowerShell in “Module 2: Microsoft Azure
management tools” of this course.
Azure CLI
The Azure CLI provides a set of commands that you can use to manage Azure subscriptions and their
components, similar to Azure PowerShell. Similar to Windows PowerShell, it runs on a variety of Linux
distributions and Mac OS X.
Note: You will learn more about the Azure CLI in “Module 2: Microsoft Azure management
tools” of this course.
Visual Studio
Developers and DevOps personnel can use Visual Studio to build projects that target different
capabilities of Azure. Typical examples include implementing Azure Web apps and mobile apps.
However, you also can develop code that performs practically any management tasks that you can
perform by using Azure PowerShell, Azure CLI, or the Azure portal.
Additional Reading: To develop applications that target Azure in Visual Studio, install the
Azure SDK for .NET, from “Downloads, Get the SDKs and command-line tools you need” at:
http://aka.ms/ywmvxt
Azure Cloud Shell

If you like the convenience of the Azure portal but want to leverage command-line capabilities, you
should consider using Cloud Shell. Azure Cloud Shell offers a command prompt window accessible
directly from the Azure portal, from which you can run Azure CLI commands.
Since Azure Cloud Shell works directly within an internet browser window, it does not depend on any
locally installed components, unlike Windows PowerShell or Azure CLI. It also does not require a separate
authentication mechanism, relying instead on the same credentials that you used to sign in to the Azure
portal.
Azure Cloud Shell requires a file share residing in an Azure storage account within the current
subscription. This provides the ability to persist modifications to this directory across separate command
line sessions. While it is possible to use Azure Cloud Shell to run scripts, its primary purpose is to provide
a way to run commands interactively directly from the Azure portal.
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 a number of popular Azure command line
utilities. It is expected that its support will be extended to include Windows PowerShell.

Question
Which of the following are limitations of the Azure classic portal?
You cannot view resources deployed by using Azure Resource Manager

templates.
You cannot view resources by using Service Management deployment model.
You cannot delegate permissions by using RBAC.
You cannot modify subscription level settings.
You cannot use tagging.

Lesson 4
Subscription management, support, and billing
To implement Azure services, you first must create an Azure subscription, which constitutes the primary
management and billing boundary for Azure services. This lesson presents the basic principles of Azure
subscriptions, describes how to manage subscription features, and provides an overview of Azure billing
options.
Lesson Objectives
 Describe the functionality of accounts, subscriptions, administrative roles, and RBAC.
 Describe the available Azure billing and support options.
 Explain how Azure pricing works.
 Describe how to estimate the cost of Azure services by using the Azure pricing calculator.
 Describe how to view resource cost, billing data, and subscription usage and quotas.
Accounts, subscriptions, administrative roles, and RBAC

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, assuming you
do not have one, and it creates a subscription
within that account. If you have an existing
account, you can add to it multiple subscriptions.
Accounts and subscriptions

An Azure account determines how Azure
subscription usage is reported, and to whom it is
reported. 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, 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 it can host.
Administrative roles and RBAC

Traditionally, Azure provided three built-in account and subscription-level administrative roles:
 Account Administrator. There is one Account Administrator for each Azure account. The Account
Administrator can access the Account Center. This enables the Account Administrator to perform a
number of billing and administrative tasks, such as, create subscriptions, cancel subscriptions,
change billing for a subscription, or change Service Administrator.
Note: A subscription’s Account Administrator is the only person who has access to the
Account Center. However, account administrators do not have any access to services in that
subscription.
Additional Reading: You can access the Azure Account Center from the Microsoft website
at: http://aka.ms/Cbnltm
 Service Administrator. There is one Service Administrator for each Azure subscription. The Service
Administrator initially is the only account that you can use to access the Azure classic portal to create
and manage services by using its interface. By default, the user account associated with this role is
the same as the account administrator when your subscription is created.
 Co-Administrator. Service administrator can create up to 200 Co-Administrators for each Azure
subscription. Co-administrators have full permissions to create and manage Azure services 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
Active Directory tenant, as this also requires Service administrator privileges.
Note: The Service Administrator and Co-Administrators are able to view the current usage
of the subscription and its quotas.
In order to comply with the principle of least privilege, you should avoid relying on Co-Administrators for
delegation of access to your subscription. Instead, when using Azure Resource Manager deployment
model, you have the option to grant a minimum required set of permissions by using the built-in or
custom RBAC roles.
RBAC allows you to provide granular access to Azure resources, down to the level of individual resources
and one or more actions on that resource. You can specify the extent of access by using a predefined or
custom role, which is assigned to an Azure Active Directory user, group, or application.
Note: You have to be either the Service administrator or a Co-administrator to access the
Azure classic portal.
Azure billing and support options

Each subscription has a specific billing option. At
the time of this course’s creation, several billing
options exist, including:
 Pay-As-You-Go. This option provides a

flexible pricing plan. You only pay for the
services that you use, and you can cancel this
subscription at any time. You can make
payments by using a credit card, a debit card,
or, if pre-approved, via an invoice.
Additional Reading: For more information

about the Pay-As-You-Go plan, including usage quotas, refer to: “Pay-As-You-Go” at:
http://aka.ms/Gote79
 Buy from a Microsoft Reseller. This option allows you to capitalize on your existing relationship with
the same reseller from whom you purchase Microsoft software under the Open Volume License
Program. In this case, you buy Open credits, and then use them to activate a new subscription or
supplement credits on an existing one.
Additional Reading: For more information, refer to: “Get Started with Azure in Open
Licensing” at: http://aka.ms/Kem08f
 Enterprise agreements. This option is best for large organizations that sign an Enterprise Agreement
and make an upfront commitment to purchase Azure services. Customers who select this option can
use the Enterprise Portal to administer their subscription. By making an up-front monetary
commitment, customers can realize significant savings.
Additional Reading: For more information, refer to: “Licensing Azure for the Enterprise”
at: http://aka.ms/Voag7x
 Azure Compute Pre-Purchase Plan. This plan involves an up-front purchase of 12 months of a
particular Azure virtual machine (VM) instance, including instance family, size, region, and operating
system. It offers significantly discounted pricing 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:
https://aka.ms/emtve7
 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:
https://aka.ms/qoc6im
Microsoft also provides a number of 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
Azure offers a number of different support options, including:
 Developer, Standard, Professional Direct, and Premier paid support plans.
 Unlimited subscription management (applicable to issues such as billing, quota management, and
account transfers).
 Azure online forums (MSDN and Stack Overflow).
 Twitter support via @AzureSupport.
 Azure service dashboard.
Additional Reading: For more information about support plans, refer to: “Azure Support
For Customers” at: http://aka.ms/cqf65f
Azure pricing
Cloud technologies generally enable you to
minimize or eliminate capital expenditures
completely. They also might help customers lower
their operational costs. These principles are
applicable to Azure and are reflected in its pricing
model.
Azure charges are, for the most part, calculated
on a per-minute basis, and they reflect actual
usage. For example, when you deploy Azure
virtual machines, the corresponding cost reflects
mainly the time during which they are online.
These charges apply whenever a virtual machine
is running, but terminate as soon as you stop it. Another, smaller part of virtual-machine cost reflects the
usage of Azure storage for virtual machine disk files. When using a Standard storage account, you are
charged for only the disk space that you use and for the number of Input/Output storage operations that
your workload performs. For example, if you provision a 1 terabyte (TB) disk, but you store only 20
gigabyte (GB) of data on it, then your cost will represent slightly above 2% of the cost of the entire disk.
Note: There are some exceptions to this rule, typically applicable to higher end services
where you pay for guaranteed, provisioned capacity. For example, with the Premium Storage
(equivalent to Solid State Drives storage), you would pay for entire 1TB disk, regardless of the
amount of data you store on it. On the other hand, in this case, there would be no charges for
the number of Input/Output storage operations performed by your workload.
Microsoft offers a majority of 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 also have the option of implementing 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 and, with respect
to licensed products, 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
Pricing calculator
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
different 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.
Demonstration: Viewing resource cost, billing data, and subscription usage

and quotas
 View your subscription’s current charges in the Azure portal.
 View the billing data in the Account Center.
 View the current usage and usage quotas in the Azure classic portal.

Question
You are a Service Administrator of an Azure subscription. What method do we recommend for
delegating the ability to manage some of your subscription’s resources to another user?
Configure the user as the Account Administrator
Configure the user as the Service Administrator
Configure the user as a Co-Administrator
Configure the user as the Owner of the subscription by using RBAC
Configure the user as the Owner of the resources by using RBAC

Lab: Using the Azure portals

Scenario
A. Datum Corporation is a manufacturing company, based in the United States, with satellite offices and
1,000 employees around the world. A. Datum does not use cloud-based services for any of its technology
needs. Its employees are well-versed in Microsoft technologies and tools, and the IT department is fully
proficient in configuring and maintaining Active Directory, and in using SQL Server, Windows Server, and
Visual Studio for administrative tasks.
However, A. Datum wants to investigate how Azure could help reduce IT deployment, management, and
development costs. A. Datum managers believe this might drastically reduce the total cost of ownership
of their applications and provide simplified world-wide access to these applications. A. Datum intends to
evaluate which of their IT services can run efficiently in Azure.
To prepare for future deployments to Azure, you plan to become familiar with the interface of the Azure
portals, focusing on their customizability and the support for retrieving billing and resource usage data.
Objectives
After completing this lab, you will be able to:
 Customize the Azure portal interface.
 Display billing and usage data for your Azure subscription
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: 20 minutes
Virtual machine: 10979D-MIA-CL1

User name: Admin
Password: Pa55w.rd
For this lab, you need to use the available virtual machine environment. Before you begin the lab, you
must complete the following steps:
1. On the host computer, start Hyper-V Manager.
2. In Hyper-V Manager, click 10979D-MIA-CL1, and then in the Actions pane, click Start.
3. In the Actions pane, click Connect. Wait until the virtual machine starts.
4. Sign in by using the following credentials:
o User name: Admin
o Password: Pa55w.rd
5. You also need to start MSL-TMG1 for internet access.

Exercise 1: Customizing the Azure portal interface

Scenario
As part of exploring the Azure portal interface, you want to customize it so you can find information
easily.
Exercise 2: Viewing billing, usage, and quotas data

Question: The lab showed you how you use different methods to view charges of services
and resources in your subscription. Which method allows you to download an Excel
spreadsheet that contains billing data?
Module Review and Takeaways

Review Question
Question: What are the three categories of cloud services?
2-1
Module 2
Microsoft Azure management tools
Contents:
Module Overview 2-1
Lesson 1: What is Azure PowerShell? 2-2
Lesson 2: Azure SDK and Azure CLI 2-8

Lab: Using Microsoft Azure management tools 2-13
Module Overview
The Microsoft Azure portals provide a graphical user interface (GUI) for managing your Azure
subscriptions and services. However, in some scenarios, the Azure portals might not offer the most
optimal management capabilities. In many cases, you might want to automate repetitive or cumbersome
administrative tasks by creating reusable scripts that you can easily write and modify. You can accomplish
this objective by taking advantage of the Azure PowerShell modules and the Azure command-line
interface (CLI). If you have programming skills, then in addition to these two command-line-based
approaches, you can also develop custom Azure management solutions by using Microsoft Visual Studio
and other programming tools.
Objectives
 Describe and use Azure PowerShell to manage your Azure subscription.
 Describe and use the Azure software development kit (SDK) and the Azure CLI to manage your Azure
subscription.
2-2 Microsoft Azure management tools
Lesson 1
What is Azure PowerShell?
Windows PowerShell provides a scripting platform intended to manage various aspects of your
computing environment. You can extend its capabilities by importing software libraries, known as
modules. Modules encapsulate Windows PowerShell code in the form of functions or compiled
assemblies, referred to as cmdlets. This principle also applies when you work with Azure. This lesson
explores how you can use Windows PowerShell in combination with Azure PowerShell modules to
connect to an Azure subscription and to provision and manage Azure services.
Lesson Objectives
 Describe Windows PowerShell.
 Describe how to use Azure PowerShell.

 Explain how to manage Azure subscriptions by using the Azure PowerShell modules.
 Install the Azure PowerShell modules and connect to Azure by using account credentials.
Introduction to Windows PowerShell

Windows PowerShell is a technology that consists
of a scripting language and the corresponding
engine responsible for script processing. The
engine is available within a host application. The
Windows operating system provides two primary
host applications. The first one, implemented as
powershell.exe, takes the form of the command-
line console. The second one, implemented as
powershell_ise.exe, provides a graphical interface,
known as the Windows PowerShell Integrated
Scripting Environment (Windows PowerShell ISE).
Some benefits of the Windows PowerShell ISE
include the ability to open, edit, and run multiple scripts simultaneously, and access to context-sensitive,
graphical help.
Launching a host initiates a new Windows PowerShell runspace, which is the environment in which the
Windows PowerShell engine operates. Windows PowerShell ISE allows you to run multiple scripts within
the same runspace. You can also run scripts in separate runspaces by opening multiple Windows
PowerShell tabs within the same Windows PowerShell ISE window.
Note: You also have the option of authoring and debugging Windows PowerShell scripts
in Visual Studio by using PowerShell Tools for Visual Studio, which is a set of tools that is
available in the Visual Studio Gallery. Alternatively, you can install and use Visual Studio Code,
which is an open source–based software that provides equivalent functionality and runs on
Windows, Linux, and Mac.
Additional Reading: For more information, refer to: “PowerShell Tools for Visual Studio
2017” at: https://aka.ms/iz4i9p
Additional Reading: For more information, refer to: Visual Studio Code:
http://aka.ms/Frdda1
Windows PowerShell cmdlets

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 either run these functions and
cmdlets interactively from the Windows PowerShell console prompt and the Windows PowerShell ISE
console pane, or incorporate them into custom scripts.
Windows PowerShell cmdlets use the syntax that follows the verb-noun format. Each noun has a
corresponding collection of associated verbs. The most common Windows PowerShell cmdlet verbs
include:
 Get
 New
 Set
 Restart
 Resume
 Stop
 Suspend
 Clear
 Limit
 Remove
 Add
 Show
 Write
You can view the available verbs for a particular Windows PowerShell noun by running the following
command:
Get-Command -Noun <NounName>
You can view the available Windows PowerShell nouns for a specific verb by running the following
command:
Get-Command -Verb <VerbName>
You can learn about the functionality of any Windows PowerShell cmdlet by using the Get-Help cmdlet.
To do so, at the Windows PowerShell console prompt or in the Windows PowerShell ISE console pane,
type Get-Help followed by the name of the cmdlet. Alternatively, you can display the Command add-on
in the Windows PowerShell ISE window.
Each Windows PowerShell cmdlet has its own associated set of parameters, which allows you to control
different aspects of its behavior. You can learn about the parameters of every Windows PowerShell
cmdlet by using the Get-Help cmdlet.
Availability of cmdlets
You can determine which Windows PowerShell cmdlets are available within your Windows PowerShell
session by running the Get-Command cmdlet. Their availability depends directly on the modules loaded
within the session. You can explicitly load an additional module by running the Import-Module cmdlet.
In the versions of Windows PowerShell included in the currently supported Windows operating systems,
the engine, by default, automatically loads any module residing at the locations included in the value of
the $env:PSModulePath Windows PowerShell environment variable. You can identify these locations by
typing $env:PSModulePath at the Windows PowerShell prompt and then pressing Enter. Typically,
whenever you install a new Windows PowerShell module, the installation process automatically updates
this variable, effectively causing the module to become automatically available the next time you start a
Windows PowerShell session. This behavior also applies to Azure PowerShell modules, which are the
focus of this lesson.
Introduction to Azure PowerShell

To manage Azure resources by using Windows
PowerShell, you first need to 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 must rely on the Azure PowerShell Service Management module called Azure. Similarly,
there are separate modules that allow you to manage Azure resources, such as Azure Active Directory,
Azure Information Protection, Azure Service Fabric, and Azure ElasticDB.
Azure PowerShell is managed as an-open source project, with the repository hosted on GitHub at:
https://aka.ms/i71tpl. It is currently supported on Windows, Linux, and macOS.
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/wiu6qp
 The PowerShell Gallery. This method relies on the capabilities built into the PowerShellGet module,
which facilitates discovery, installation, and updates of some Windows PowerShell artifacts, including
other Windows PowerShell modules. PowerShellGet relies on the functionality built into Windows
Management Framework (WMF), which is part of the operating system, starting with Windows 10
and Windows Server 2016. The same version of WMF is also available at https://aka.ms/esnimz. 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/vjyen6.
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. In particular, 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/n4hlto
Additional Reading: For more information, refer to: PackageManagement PowerShell

Modules Preview: http://aka.ms/Onym5y
 Microsoft 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, but 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, then you can import a specific
version by adding the –RequiredVersion parameter when running the Import-Module cmdlet.
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.
Managing Azure subscriptions by using Azure PowerShell

After you install the Azure PowerShell modules, you
can connect the Azure PowerShell session to the
Azure subscriptions that you want to manage. To
establish this connection, you first need to
authenticate by using an account that exists in the
Azure AD tenant, which is associated with the
target subscription. This can be a Microsoft account
that you either used to create the subscription or
added subsequently to the subscription’s Azure AD
tenant. Alternatively, you can also create new
accounts in Azure AD. These accounts were
formerly referred to as organizational accounts and
are now known as work or school accounts.
When managing Azure Resource Manager resources, you authenticate by running the Add-
AzureRmAccount cmdlet. By default, running this cmdlet opens a browser window prompting you for
the user name and the password of a user account with access to the Azure subscription that you intend
to manage.
Azure AD authentication is token-based, and after signing in, the user remains authenticated 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/k2mtil
After you authenticate, you can use the Get-AzureRmSubscription cmdlet 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 Set-AzureRmSubscription cmdlet and providing either the subscription name or
ID. You can identify the subscription name and ID by reviewing the output of the Get-
AzureRmSubscription cmdlet.
After you authenticate from within a Windows PowerShell session, Azure PowerShell automatically
generates a collection of session-related objects, which is known as the session context. That context
contains objects such as the account, Azure subscription, and corresponding Azure AD tenant. You can
manage the content of the context by using the Set-AzureRmContext and Select-
AzureRmSubscription cmdlets and view the context by using the Get-AzureRmContext cmdlet.
When managing Azure Service Management services, you authenticate by running the Add-
AzureAccount cmdlet. For access to subscription management functionality that is equivalent to that
from Get-AzureRmSubscription and Select-AzureRmSubscription, you can run the corresponding
Azure PowerShell cmdlets, including Get-AzureSubscription and Select-AzureSubscription. However,
in this case, no corresponding session context exists, so you need to manage its components separately.
After you authenticate and establish a session context, you can use Azure PowerShell cmdlets to view,
provision, and manage Azure services and resources. You will learn about these cmdlets in the upcoming
modules of this course.
Demonstration: Installing the Azure PowerShell modules and connecting

to an Azure subscription
 Install the Azure PowerShell modules.
 Connect an Azure PowerShell session to your Azure subscription.
 Use Azure PowerShell cmdlets.

Question
Which cmdlet should you use if you want to authenticate to your subscription and manage Azure
Resource Manager resources?
Select-AzureRmSubscription
Add-AzureAccount
Add-AzureRmAccount
Select-AzureSubscription
Get-AzureRmContext
Lesson 2
Azure SDK and Azure CLI
The Azure SDK allows developers to use their programming skills to develop a variety of applications for
Azure. The Azure CLI provides an alternative to Windows PowerShell for administrators who are more
familiar with operating systems other than Windows and Linux or UNIX-based shell scripting. This lesson
provides an overview of these two management methodologies.
Lesson Objectives
 Describe the components of the Azure SDK.
 Describe the Azure CLI.
 Explain how to install and use the Azure CLI.
What is the Azure SDK?

The Azure SDK is a collection of tools, runtime
binaries, client libraries, and templates that
considerably simplify the development, testing, and
deployment of Azure services and applications.
Note: The Azure SDK is available for several

development platforms, including Microsoft .NET,
Java, Node.js, Python, Ruby, and PHP. You can
download the most recent version of the SDK for
each of them from the Azure Downloads page.
Additional Reading: For more information,

refer to: “Downloads” at: http://aka.ms/Nc0773
The Azure SDK for .NET installs numerous components, including:
 Microsoft ASP.NET and Web Tools for Visual Studio to facilitate the creation, deployment, and
management of web apps.
 Azure Tools for Visual Studio to simplify working with applications hosted in Azure Platform as a
Service (PaaS) cloud services and Infrastructure as a Service (IaaS) virtual machines.
 Azure Authoring Tools to automate the deployment and configuration of Azure PaaS cloud services
deployment packages.
 The Azure emulation environment, which consists of the Azure compute and storage emulators to
simulate Azure compute and storage services within the Visual Studio interface.
 Azure Storage Tools to provide tools, such as AzCopy, that allow you to optimize the transfer of data
into and out of an Azure Storage account.
 Azure Libraries for .NET, such as NuGet packages for Azure Storage, Azure Service Bus, and Azure
Cache, to make it possible to develop Azure projects while offline.
Note: NuGet is the package manager for the Microsoft development platform.
 Azure Resource Manager Tools, including templates, snippets, and scripts to assist with creating and
deploying Azure Resource Management resources.
 Azure Diagnostics with Visual Studio Application Insights integration and support for the profiler to
allow you to identify and diagnose performance-related issues in live Azure apps and services.
 Docker Tools for Visual Studio to provide support for Windows containers.
 Azure Service Fabric Tools to enable creating, deploying, and upgrading Azure Service Fabric
projects from within Visual Studio.
 Azure HDInsight Tools for Visual Studio to allow you to run your Hive query and provide insight into
HDInsight job execution.
 Azure Data Factory Tools to simplify Azure Data Factory authoring.
Additional Reading: For more information, refer to: “What is the Azure SDK for .NET?" at:
http://aka.ms/Rixh0i
Introduction to the Azure CLI

The Azure CLI provides a command-line, shell-
based interface that you can use to interact with
your Azure subscriptions. Generally, the Azure CLI
offers the same 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 use
their existing skills.
At the time of authoring of 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/q3asut
 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/qa9tdx
Azure CLI 2.0 supports exclusively the Azure Resource Manager deployment model. If you still manage
any classic resources, you can run both versions side-by-side. As a matter of fact, both CLIs by default
share credentials you provide and the Azure subscriptions you select, 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 macOS. 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 the
majority of Linux command-line tools without any modifications.
Note: Bash on Windows is in preview during the authoring of this course.
The installation process for Azure CLI depends on its version and 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 macOS operating systems
from https://aka.ms/hpgu45. Similarly, Python is a prerequisite for installing Azure CLI 2.0. Python
installers are available at https://aka.ms/kxr1ze.
Installing Azure CLI 1.0

After you install Node.js, you can use the Node package manager nmp 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 this, use the
docker command-line utility 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 macOS.
Additional Reading: For more information about installing Azure CLI 1.0, refer to:
“Microsoft Azure Xplat-CLI for Windows, Mac and Linux” at: https://aka.ms/q3asut
Installing Azure CLI 2.0

To install Azure CLI 2.0, you can use precompiled installers for Windows, Linux, and macOS. 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 macOS 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/ultvco
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 a command shell on Linux or
macOS.
After you install the Azure CLI, you can connect to the Azure subscriptions that you want to manage.
Similar to the Azure PowerShell modules, to establish such a connection, you first need to authenticate
by using either a Microsoft account or a work or school account that exists in the Azure AD tenant
associated with the target subscription.
To initiate the authentication process, run one of the 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 generates. This step verifies the Azure CLI as the application publisher and allows you to
type your user credentials to authenticate to the Azure subscription.
Azure AD authentication is token-based, and after signing in, the user remains authenticated until the
authentication token expires.
After you authenticate, you can use the azure account list command (in Azure CLI 1.0) or az account list
command (in Azure CLI 2.0) to view a list of subscriptions associated with your account. If you have
multiple subscriptions, you can specify which you want to manage by using the azure account set
command (in Azure CLI 1.0) or az account set command (in Azure CLI 2.0) 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 command (in Azure CLI 1.0) or az account list command (in Azure CLI 2.0).
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: Installing and using the Azure CLI

 Install the Azure CLI.
 Use the Azure CLI.


Question
You have successfully authenticated and connected to your Azure subscription in an Azure
CLI 1.0 session. You currently manage Azure Resource Manager resources. Which Azure CLI
command should you run if you want to manage Azure classic resources?
azure config mode arm
azure config mode asm
azure login
azure account list
azure account set

Lab: Using Microsoft Azure management tools

Scenario
To prepare for the deployment of Azure services, you want to become familiar with the primary Azure
management tools. Most of your on-premises administrative tasks are automated by means of Windows
PowerShell scripts and Linux shell scripts. You have decided to test the use of Azure PowerShell and the
Azure CLI.
Objectives
 Install the Azure PowerShell modules and the Azure CLI.
 Use Azure PowerShell and the Azure CLI to connect to your Azure subscription.
 Run Azure PowerShell cmdlets and Azure CLI commands against your Azure subscriptions.
Lab Setup
User name: Admin
Password: Pa55w.rd
For this lab, you need to use the available virtual machine environment. Before you begin the lab, you
must complete the following steps:
3. In the Actions pane, click Connect. Wait until the virtual machine starts.
o User name: Admin
Question: What must you do in order to use Azure CLI to manage classic resources?

Review Question
Question: Which method would you choose to automate the management of your Azure
environment?
3-1
Module 3
Virtual machines in Microsoft Azure
Contents:
Module Overview 3-1
Lesson 1: Creating and configuring VMs 3-2
Lesson 2: Configuring disks 3-15

Lab: Creating a VM in Azure 3-22
Module Overview
Microsoft offers several virtualization management technologies to help your organization resolve
problems that you might encounter when managing server computing environments. For example,
server virtualization helps reduce the number of physical servers, and provide a flexible and resilient
server solution. You can deploy virtual machines (VMs) on your locally installed servers or in Microsoft
Azure. In this module, you will learn how to create and configure VMs in Azure, and how to manage their
disks.
Objectives
 Create and configure VMs in Azure.
 Configure disks for VMs.

3-2 Virtual machines in Microsoft Azure
Lesson 1
Creating and configuring VMs
VMs provide many benefits over traditional physical machines. You can create VMs on physical servers in
your IT environment, or you can choose to create VMs in Azure. In this lesson, you will learn how to
create and configure VMs in Azure.
Lesson Objectives
 Describe the purpose and functionality of Azure VMs.
 Describe how to create VMs from the Azure portal.

 Create a VM from the Azure portal by using an Azure Marketplace image.
 Create a VM from an Azure Resource Manager template.
 Configure VM availability.
 Deploy VMs into an availability set by using the Azure portal.
 Configure an operating system by using VM extensions.
 Connect to a VM.
What are Azure VMs?

Azure VMs are similar to VMs that run on Microsoft
Hyper-V hosts in on-premises datacenters.
However, in addition to some technical differences,
which we will cover in more detail later in this
lesson, Azure VMs offer extra benefits when
compared with their on-premises counterparts. In
particular, Azure VMs are similar to other cloud-
based services because they deliver superior agility,
enabling you to provision and deprovision them on
an as-needed basis, without investment in
dedicated hardware. This makes Azure VMs the
most applicable solution for a number of different
scenarios. One example is an environment that must accommodate dynamically changing demand (such
as customer-facing websites that must quickly adjust to fluctuations in their workload). Another example
is a scenario that involves temporary setup (frequently required by proof-of-concept or development
projects).
When you run Azure VMs, you pay for the compute time on a per-minute basis. The price for a VM is
calculated based on its size, the operating system, any licensed software installed on it, and the Azure
region in which it resides. A running virtual machine requires allocation of Azure compute resources, so
to avoid the corresponding charges; you should change its state to Stopped (Deallocated) whenever you
are not using it.
Note: Shutting down an Azure VM from within its operating system will result in a
Stopped state, which will still incur computing charges.
Note: Note that there are additional charges associated with the Azure Storage hosting
VM disk files. These charges apply regardless of the state of the VM.
While you do not have full console access to Azure VMs (as you do when you manage the underlying
Hyper-V host), the Azure portal offers the boot diagnostics functionality. This allows you to view both the
console log and the screenshot of its display.
One benefit of Azure VMs is their compatibility with on-premises Hyper-V VMs. This simplifies migrating
your existing systems to the cloud by uploading existing virtual hard disk (.vhd) files to the cloud. It also
facilitates integrating both environments, making Azure an extension of your organizational datacenters.
Note: At the time of authoring of this course, Azure does not support Generation 2 VMs,
introduced in Windows Server 2012 R2.
Deploying Azure VMs

Deploying VMs in Azure is different from deploying them in an on-premises Hyper-V environment. When
you manage the hypervisor platform, you have the ability to configure all VM settings any way you like.
In Azure, you select from a range of predefined configuration options corresponding 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: A temporary disk of an Azure VM resides on the Hyper-V host where the VM runs.
Its operating system and data disks reside in Azure Storage. You will learn more about them in
the second lesson of this module.
Note: Note that the number of different VM sizes is significant and sufficient to satisfy a
majority of requirements. At any point, you also have the ability to switch between different
configurations, as long as your current configuration does not violate constraints of the one you
want to switch to (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 its restart.
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 non-production workloads
that do not require features such as load balancing, autoscaling, or high availability, and for which you
are willing to tolerate disk I/O in the range of 300 Input/Output Operations Per Second (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 than 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 megabytes (MB) of memory, and a single data disk. As the largest
VM in this tier, the Basic A4 VM offers 8 CPU cores, 14 gigabytes (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.
A number of standard VM sizes offer Microsoft Azure Premium Storage. These sizes support high-end
storage and provide performance equivalent to that of solid-state drives (SSDs). 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: You will learn more about Premium Storage later in this course.
VM sizes in Azure
Each VM size is represented by a combination of one or more letters and numbers. 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. These characteristics typically include:
 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. VM sizes that
support Premium Storage also differ in 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. This category is also suitable for hosting
small to medium databases or web servers. This category includes A0-A7, Av2 series, D series, Dv2
series, DS series, and DSv2 series VM sizes.
 Compute-optimized. This category offers a high CPU-to-memory ratio, making it most suitable for
compute-intensive workloads without 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 without extensive compute requirements. Such characteristics are
typical for workloads that keep most of their operational content in memory, such as database or
caching servers. This category includes D, Dv2, DS, DSv2, M, 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 graphics 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 and A8-A11 VM sizes.
Note: For the up-to-date list of VM sizes and additional information regarding their
characteristics, refer to: “Sizes for Windows virtual machines in Azure” at: http://aka.ms/Iyrbvv
Create a VM by using the Azure portal

Creating a new VM by using the Azure portal is a
relatively straightforward process. However, it
involves several steps, which you should be familiar
with to implement the most optimal configuration.
The first step involves choosing the origin of the
operating system that automatically installs on the
VM. You can choose any Azure Marketplace image
available to you.
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. Some of 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
Note: When you use the Azure portal to provision an Azure VM, you must choose a
Marketplace image that will serve as the basis for the VM deployment. Other provisioning
methods, including Azure PowerShell, Azure Command-Line Interface (Azure CLI), and Azure
Resource Manager templates, offer more flexibility, giving you two additional options for
deploying an Azure VM:
 A Windows or Linux operating system image that you uploaded to Azure from your on-premises
image repository or created from an existing Azure VM.
 A Windows or Linux operating system disk that you uploaded to Azure from your on-premises VM
repository or created from an existing Azure VM.
You will learn about disks and images in the second lesson of this module.
After you select an image, you should decide whether to use the Azure Resource Manager or classic
deployment model. Typically, you choose the Azure Resource Manager deployment model unless the
solution you intend to implement does not support Azure Resource Manager–based VMs.
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 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 nonmanaged disks. Managed
disks minimize the overhead involved in administering disk placement in Azure Storage. They also
provide functional benefits that are not available with nonmanaged disks. If you choose
nonmanaged 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.
Note: You will learn about managed disks in the next lesson of this module.
 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 (you will learn more about virtual networks in Module 5,
“Creating and configuring 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 (more about this in Module 5).
 Public IP address. This option allows you to (optionally) provide an internet-accessible IP address to
facilitate connectivity to the VM from:
o Outside of Azure, including on-premises environments or third-party 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 Azure-provided network-level controls (functionally
equivalent to a firewall) that apply to incoming and outgoing traffic. You define these controls by
creating a combination of allow and deny rules applicable to specific IP source and destination
ranges, corresponding ports, and transport protocols. The default security group that the Azure
platform provisions in this case allows connectivity from the internet to TCP port 3389 of the Azure
VM. The purpose of this configuration is to permit inbound Remote Desktop Protocol (RDP) sessions
after the VM deployment is completed. 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 as with a Windows VM. There are two
primary differences:
 You can choose between the password-based and Secure Shell (SSH) public key–based
authentication types.
 The default network security group allows connectivity from the internet to port 22 on the VM. The
purpose 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 a number of these options might sound confusing initially, the default settings yield the
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 Remote Desktop
Protocol (RDP) (in the case of a Windows image) or SSH (for Linux distributions) from any system with
internet access. Obviously, the ability to connect successfully to the VM is contingent on the knowledge
of its administrative credentials.
Demonstration: Create a VM from the Azure portal by using an Azure

Marketplace image
In this demonstration, you will see how to create a VM from the Azure Portal by using an Azure
Marketplace image.
Creating a VM from an Azure Resource Manager template

You can also create VMs by using Azure Resource
Manager templates. This deployment option is
straightforward, but can be more complex
depending on how much you want to customize
the VM configuration. This option relies on the
capability that Azure Resource Manager
introduced, which makes 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 JavaScript
Object Notation (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, every deployment based on the same template might potentially result in a different outcome,
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, use the -TemplateFile parameter. This results in a deployment of 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 that are 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 install their scripting engines (unless you use Azure
Cloud Shell) and be familiar with their syntax. A more convenient way of deploying Azure Resource
Manager template–based resources is available directly from the Azure portal through the New >
Compute > Template deployment hub menu entries. When you select these 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. In addition, the
same GitHub page has a 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
with a Resource Manager template” at: http://aka.ms/Bt1gf6
Demonstration: Creating a VM from an Azure Resource Manager template

In this demonstration, you will see how to create an Azure VM from an Azure Resource Manager
template.
Configuring VM availability
It is important that your Azure VM–based solutions
be resilient to hardware failures and maintenance
events that might occur occasionally within the
Azure infrastructure. The availability set is the
primary mechanism that the Azure platform
provides to help you accomplish this objective. 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 infrastructure as a service (IaaS), some of them might
involve reboots of Hyper-V hosts, which affect availability of their VM guests.
 Hardware failures. While the Azure platform is designed to be highly resilient, there might be cases
where a hardware failure brings down 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 addresses 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 Microsoft Azure Service Fabric can
update and reboot 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 rebooted 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 failures of individual VMs by placing VMs hosting applications, such as
web or database servers, in a function-based availability set. Then you can use load balancing or a
failover mechanism across VMs in that 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, in case of Azure Resource
Manager–based deployments, a JavaScript Object Notation (JSON) template. You have the option of
creating a new availability set while deploying a new VM, or creating a new availability set first and then
adding VMs to it. However, you must add a VM to an availability set at the deployment time. At the time
of authoring this course, it is not possible to add an existing VM to an availability set.
With the introduction of managed disks, you can create two types of availability sets managed and
unmanaged. In a managed availability set, all VMs use managed disks exclusively. In an unmanaged
availability set, all VMs use nonmanaged disks exclusively. A managed availability set automatically
ensures additional resiliency at the Azure Storage level.
Note: You will learn about managed disks in the next lesson of this module.
Note: For internet-facing VMs to qualify for a 99.95 percent external connectivity service
level agreement (SLA), they must be part of the same availability set (with two or more VMs per
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.
Scaling VMs in an availability set

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 in the same availability set.
We have covered the VM sizes earlier in this lesson, so we will focus on the second of these two
methods.
You implement horizontal scaling of Azure VMs by using Azure Virtual Machine Scale Sets (VM Scale
Sets). A VM scale set consists of a group of automatically provisioned Windows or Linux VMs that share
identical configurations and deliver the same functionality to support a service or application. With a VM
scale set, it is possible to have the number of VMs increase or decrease, adjusting dynamically to changes
in demand for the workload they host.
Note: VM 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 pre-provisioning additional VMs that you want to bring online to
accommodate increased demand.
Note: VM scale sets support five fault domains.
Note: For more information, refer to: “Virtual Machine Scale Sets Overview” at:
http://aka.ms/xl3xw5
Demonstration: Deploying VMs into an availability set by using the Azure

portal
In this demonstration, you will see how to configure Azure VMs in an availability set.
Configuring an operating system by using VM extensions

When deploying Azure VMs, in addition to
implementing platform-specific configurations
(such as Azure Storage or virtual network settings),
you can also configure the operating system and
applications running in the VM. You use a software
component called the Azure VM agent to perform
these configurations. The VM agent includes
several of its own useful features, in addition to
support for loading software components called
VM extensions. These VM extensions implement
additional functionality, typically in the areas of
management, monitoring, or security.
VM images available from the Marketplace include the VM agent by default. When creating custom
images, you should install the agent manually before generalizing the operating system. The Windows
VM agent is available from https://aka.ms/a4hnxc as a Windows Installer package. Linux operating
system versions of the VM agent are available for download from GitHub. After the installation
completes, you also need to set the ProvisionGuestAgent property of the VM via Azure PowerShell or
Azure CLI.
After you install the agent, you can add VM extensions. Some of the more commonly used VM
extensions include:
 Background Info extension. This extension displays desktop background on Windows VMs. The
background contains such information as the computer name, total amount of memory allocated to
it, its IP address, or the operating system version.
 Azure VM Access extension. This extension enables you to reset local administrative credentials and
fix misconfigured RDP settings on Windows VMs.
 Azure VM Access extension for Linux. This extension enables you to reset the admin password or
SSH key, fix misconfigured SSH settings, create a new sudo user account, or 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 Windows Azure VMs. The most common use of the Custom Script
extension involves applying custom configuration settings during VM provisioning. However, it is
also possible to use it to perform any scriptable action after the initial deployment. Scripts can reside
in 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 operating system 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, its components, and applications, including the ability to modify such settings as file,
folder, registry, service, or an operating system feature.
 DSC extension for Linux. This extension implements a template-based configuration of Linux
operating systems, equivalent to the one that PowerShell DSC provides for Windows.
 Azure Diagnostic extension. This extension enables Azure VM diagnostics that collect data from the
operating system 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/qb84ta
Connecting to a VM
After the Azure VM you created with default
settings is running you will be able to connect to it.
The connectivity method will depend on the
operating system running within the VM:
 RDP allows you to establish a GUI session to an

Azure VM that runs any supported Windows
operating system. The Azure portal
automatically enables the Connect button on
the Azure Windows VM blade if the VM is
running. The VM has a public IP address and its
network security group includes a rule that
permits inbound connections 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 delivers the
same outcome when you invoke it from the Windows PowerShell console.
 SSH allows you to establish a command-line interface session to an Azure VM that runs the Linux
operating system. To establish such a session from a Windows computer, you typically use a terminal
emulator, such as PuTTY. Most Linux distributions offer the OpenSSH package. There are several
open source and non-Microsoft SSH client programs available for both Windows and Linux.
For security reasons, you can disable connectivity to Azure VMs from the internet by removing the public
IP address associated with their network adapters. After doing so, you would be able to connect to them
from a VM on the same Azure virtual network. You could also connect to them from your on-premises
computers, if you establish a connection to the target virtual network via a virtual private network (VPN)
tunnel or a private circuit (you will learn about this type of configuration in Module 5 of this course).
If removing the public IP address associated with an Azure VM is not an option, you can narrow the
scope of IP addresses from which a connection to that VM can originate. To accomplish this, you must
modify the network security group rule that allows incoming traffic via the RDP or SSH port. This is
feasible when you know the IP address representing the public endpoint of the computers from which
you intend to establish an RDP or SSH session.
To sign in to a newly provisioned VM, you use credentials that you specified during its creation. When
connecting via SSH, it is also possible to use certificate-based authentication, assuming that you selected
the SSH public key authentication type when creating the target Linux VM.
Note: As briefly mentioned in the previous topic, if you forget the password for the Azure
VM, you can perform a password reset by using the VM Access extension.
Each Windows VM created by using an Azure Marketplace image has its local Windows Firewall enabled.
By default, Windows Firewall has the rule that allows incoming RDP connections enabled. However, if you
want to allow connectivity on a different port, you might need to configure Windows Firewall
accordingly.
The same principle applies to Azure network security groups associated with a newly created VM. By
default, such a group will include a rule allowing connectivity via RDP or SSH (depending on the
operating system of the VM). Enabling incoming connections on other ports would require the addition
of extra rules to the security group.
Additional Reading: You can connect to an Azure Linux VM via Remote Desktop by using
functionality that the xrdp open source RDP server provides. To accomplish this, you must install
xrdp on the target Linux VM. For more information, refer to: “Using Remote Desktop to connect
to a Microsoft Azure Linux VM” at: https://aka.ms/i32wgz
Demonstration: Connecting to a VM
In this demonstration, you will see how to connect to an Azure VM.

Question
What is the maximum number of fault domains in an availability set consisting of Azure VMs that
were deployed by using the Azure Resource Manager deployment model?
20
50
Lesson 2
Configuring disks
Azure VMs use disks for different purposes, including hosting operating systems, data, and temporary
files. In this lesson, you will learn about the types of disks that VMs use and how to manage and
configure these disks. You will also learn how to attach new and existing disks to VMs, and how to use
Storage Spaces within a VM to configure multidisk volumes.
Lesson Objectives
 Describe virtual hard disks.
 Describe and implement managed disks in Azure.
 Upload and attach disks to VMs.
 Describe how to configure new disks in Windows and Linux operating systems.
 Configure disks.
Overview of virtual hard disks

Operating system and data disks of Azure VMs are
stored as .vhd files within an Azure Storage
account. An Azure Storage account is a logical
namespace that, depending of its type, can host
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, and Azure CLI.
Note: In this module, we will focus 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 Module 6, “Cloud storage.”
Azure offers two tiers of Azure Storage accounts capable of storing .vhd files—Standard and Premium. In
both, 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 terabytes (TB) in size. However, the maximum size of a
VM disk that 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 is subtle but 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 the
case of Ubuntu)
o Provides temporary, nonpersistent storage (commonly used as the location of a paging file)
o Uses SSD storage on most VM sizes (except Basic and Standard A0-A7)
 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 a storage account. The temporary
disk is implemented as local storage on the Hyper-V host where the VM is running.
Overview of managed disks

One decision you must make when deploying an
Azure VM is choosing the type of disk to attach.
You can use either the nonmanaged or managed
disk type. Your decision will affect the VM’s
functionality, manageability, and pricing.
In a traditional approach, the deployment of an
Azure VM requires designating an Azure Storage
account to host the operating system disk. In
addition, if you decide to attach data disks to the
Azure VM, you can use the same or a different
Azure Storage account in the same Azure region.
These extra steps do not constitute significant
overhead if the number of Azure VMs is small. However, with larger number of Azure VMs, management
of storage accounts results in increased complexity for the following 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. With the Azure
platform allocating 500 IOPS per single standard storage disk, this implies the practical limit of 40
concurrently active disks per single Azure Storage account.
In addition to capacity and performance considerations, there is also the matter of resiliency. The Azure
platform, by default, automatically replicates every Azure Storage account across three identical copies
within the same storage cluster synchronously. However, the general recommendation is to also ensure
that Azure VMs in the same availability set store their disk files in separate Azure Storage clusters. These
clusters are referred to as storage stamps. A single storage stamp contains multiple storage accounts.
The primary challenge is ensuring that the storage accounts you create for individual VMs in the same
availability set reside in different storage stamps.
Note: You can determine whether two storage accounts reside in the same storage stamp
by resolving their fully qualified domain names to the corresponding IP addresses. If the IP
addresses are different, the storage accounts reside in different storage stamps. However, 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 reach out to Azure support and submit a request to perform this
task for you.
You can eliminate all these challenges 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. Using managed disks results in 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 on 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 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
nonmanaged disks, you must store Azure VM disks in the same storage account as the image.
Note: There is an extra cost associated with these benefits. When using Azure standard
storage with nonmanaged disks, you pay only for the space you use. With managed disks, you
pay for the full capacity of a disk, regardless of the amount of 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 nonmanaged 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 nonmanaged disks to managed disks;
however, this requires stopping and de-allocating all VMs in the availability set.
Azure VMs disk mobility
Cross-premises Azure VMs disk

operations
When you create a VM based on an image, the
Azure platform will automatically provision a new
operating system disk. Alternatively, you have the
option of attaching an existing disk containing an
operating system to a 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, you should keep in mind that, traditionally,
Hyper-V VHDs use the .vhd format (identified by the .vhd extension). Windows Server 2012 introduced a
new type of VHD with the .vhdx extension. 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 need to 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 that you should take into account 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 a number of extra
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.
 Both cmdlets also support multithreading for increased throughput.
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. The Add-AzureRmVmDataDisk cmdlet supports attaching an existing data disk
to a VM, including creating a new data disk for a VM. Conversely, you can use Remove-
AzureRmVmDataDisk cmdlets to detach an existing data disk from a 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.
The service accommodates transfers of larger amounts of data between on-premises locations and Azure
Storage accounts, whenever its size makes it too expensive or unfeasible to rely on network connectivity.
The process involves creating either import or export jobs, depending on the direction of transfer:
 You create an import job to copy data from your 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. Once the drives arrive at the destination, 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 the
creation of copies and snapshots of VHD files within Azure. You can use different methods to copy Azure
Storage blobs, such as the AzCopy command line tool available from https://aka.ms/downloadazcopy.
Alternatively, you can use the Start-AzureStorageBlobCopy Azure PowerShell cmdlet and its Azure CLI
equivalent az storage blob copy, which can perform asynchronous copy of a blob between two Azure
Storage accounts. These tools facilitate copy operations of both managed and nonmanaged disks and
images. Nonmanaged disks also support both incremental and full snapshots via Snapshot Blob REST
API.
Additional Reading: Azure REST API is beyond the scope of this course. If you want to
explore this topic further, refer to: “Snapshot Blob” at: https://aka.ms/dupgph
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 disk.
Note: At the time of authoring this course, managed disks support only full snapshots.
Configuring storage in Windows and Linux VMs

When you attach one or more disks to the Azure
VM, you manage them as you would manage a
disk on the physical machine or a VM deployed
locally on your Hyper-V server. On Windows VMs,
this involves using Server Manager or Windows
PowerShell. On Linux VMs, for multidisk
configurations, you can use Logical Volume
Manager (LVM) or mdadm utilities.
Using Storage Spaces for Windows 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 earlier versions of Windows). In general, the I/O throughput of a multidisk volume
is an aggregate of throughput of individual disks.
 Three-way mirroring, offering higher resiliency than two-way mirror or parity configurations.
However, note that this benefit does not offer a meaningful advantage in the case of Azure VMs, due
to resiliency built into the Azure platform.
 Support for volumes larger than the 4-TB size limit of a single disk in Azure VMs.
To create a storage space in a Windows operating system that runs in an Azure VM, use the following
steps:
1. Create a new VM running Windows Server 2012 or later. Avoid using lower-tier VMs, because they
support fewer data disks.
2. Attach new, empty disks to the VM.
3. Connect to the Windows operating system that runs 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 click Tasks.

7. Click New Storage Pool, and add the empty disks to the pool.
8. In File and Storage Services, select the pool, and then, in the Virtual Disks pane, click New Virtual
Disk.
9. Set the disk layout and size, and click Create.
10. Finally, in the New Volume Wizard, select the virtual disk that you created, select a drive letter, and
then create the volume.
Additional Reading: For more information regarding LVM, refer to: “Configure LVM on a
Linux VM in Azure” at https://aka.ms/d44xh4. For more information regarding mdadm, refer to:
“Configure Software RAID on Linux” at https://aka.ms/n8yavz.
Demonstration: Configuring disks

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

Question
You have a Microsoft Azure VM that runs Windows Server 2016 with a single data disk with a size
of 4 TB. You need to create a 7-TB file system volume. What should you do?
Attach one disk. 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 one disk. Create a Storage Spaces–based volume with the parity layout.
Convert the data disk to Premium Storage and increase the size of the disk.
Lab: Creating a VM in Azure

Scenario
Orders at A. Datum Corporation have increased significantly. Currently, the order system runs on an
on-premises server which provides other services. You have decided to migrate the order system to a
dedicated Azure VM. The VM must include sufficient local storage to accommodate increased volume of
orders.
Objectives
 Create an Azure VM by using the Azure portal.
 Connect to a VM by using RDP.

 Attach a data disk to a VM.
 Create a multidisk volume by using Storage Spaces.
Lab Setup

User name: Admin
Password: Pa55w.rd
For this lab, you need to use the available VM environment. Before you begin the lab, you must complete
the following steps:
3. In the Actions pane, click Connect. Wait until the VM starts.
o User name: Admin
Question: What type of connection can you establish to the VM in Azure by default?

This module covered the implementation of Azure VMs. When compared with on-premises Hyper-V
environments, Azure provides greater agility and scalability, allowing you to provision and deprovision
VMs on an as-needed basis, without the need for infrastructure investments.
You can deploy Azure VMs by using several different methods and by using a wide range of
preconfigured templates for both Microsoft and Linux operating systems. You can use VM scale sets and
availability sets to increase availability of services and applications that run on Azure VMs.
You also have the option of increasing the amount of storage assigned to Azure VMs up to a total of
256 TB.
Review Questions
Question: How does your organization use virtualization? Did you implement any public or
private cloud solutions with your virtualization solution?
Question: Based on what you learned in this module, for what purpose would you choose Azure
VM deployment?
4-1
Module 4
Web Apps and cloud services
Contents:
Module Overview 4-1
Lesson 1: Creating and configuring web apps 4-2
Lesson 2: Deploying and monitoring web apps 4-10
Lesson 3: Creating and deploying PaaS cloud services 4-18

Lab: Web Apps and cloud services 4-23
Module Overview
Microsoft Azure provides a specialized service that you can use to deploy any web app without having to
configure and maintain a virtual machine or a web app platform on it. If you create a web app using the
Web Apps feature of Microsoft Azure App Service, you can base it on a preconfigured web app platform,
including WordPress, Drupal, and Umbraco. Alternatively, you can upload a custom web app from
Microsoft Visual Studio or another web developer tool.
Another option that allows you to deploy Microsoft-managed web apps in Azure relies on the Azure
Platform as a Service (PaaS) cloud services. Azure PaaS cloud services use a modular architecture for
hosting multitier web apps. This architecture facilitates horizontal and vertical scalability without the need
for managing each individual virtual machine involved in the scaling process. This module describes the
Web Apps feature of Azure App Service and Azure PaaS cloud services.
Objectives
 Create and configure web apps by using the Azure portal.
 Deploy and monitor web apps in Azure.
 Create and deploy Azure PaaS cloud services on Azure.

4-2 Web Apps and cloud services
Lesson 1
Creating and configuring web apps
The Web Apps feature of Azure App Service offers you a customized platform to host websites and web
applications and is a prevalent technology in both Azure and on-premises deployments. In this lesson,
you will learn about Azure web apps and how they differ from the Azure Platform as a Service (PaaS)
cloud services and web apps hosted on Azure Virtual Machines. You also will learn how to create and
configure web apps by using the Web Apps feature of Azure App Service.
Lesson Objectives
 Describe the Web Apps feature of Azure App Service and compare it with Azure Virtual Machines
and Azure Cloud Services hosting web apps.
 Explain how to create a web app by using the Azure portal.

 Explain how to configure and scale a web app by using the Azure portal.
 Create and configure a web app.
Web Apps as a component of Azure App Service

Web Apps constitutes a distinct Azure service.
However, it is closely related to several other
Azure services and is typically presented as part
of this larger group known as Azure App Service.
App Service provides a comprehensive platform
for building and hosting cloud-based applications
that end users can consume from any device.
Most commonly, developers rely on App Service
to build mobile and web apps. However, App
Service also includes support for the development
and hosting of APIs and for execution of
workflows to implement arbitrary business logic.
App Service delivers a cohesive, consistent, and more powerful alternative to several separate legacy
Azure services, including Azure web apps, Azure Mobile Services, Azure API Services, and Azure BizTalk
Services.
App Service provides the following features:
 Web Apps. For developing, configuring, hosting, and managing web apps.
 Mobile Apps. For developing, configuring, hosting, and managing mobile apps.
 API Apps. For developing, hosting, and consuming web-based APIs.
 Logic Apps. For implementing cloud-based, event-triggered workflows that integrate distinct
Software as a Service (SaaS) apps (with minimal or no programming).
The first two lessons of this module focus on the Web Apps feature. Its functionality allows developers to
take advantage of a familiar set of tools and frameworks to create web apps, track their versioning,
update them with new features, and monitor them throughout their lifetime. The Web Apps feature
supports a wide range of popular programming languages, such as C#, HTML5, PHP, Java, Node.js, and
Python, and fully integrates with commonly used tools such as Microsoft Visual Studio or GitHub.
The key capabilities of Web Apps include:
 Marketplace-based solutions. You can use Azure Marketplace to choose from a wide range of
solutions that simplify the development and deployment of the most popular types of web apps.
You can find the full list of such solutions in the Web apps section of the Marketplace at:
http://aka.ms/T7tb1w.
 Autoscaling. You can configure a dynamic increase or decrease in the number of instances of web
apps to automatically adjust to variations in their workload. Auto-scaling integrates with the Azure
load balancer and distributes incoming requests among all instances.
 Continuous integration. You can deploy the web app code from cloud source control systems, such
as Visual Studio Team Services or GitHub, from on-premises source control systems, such as Team
Foundation Server (TFS) or Git, as well as from on-premises deployment tools, such as Visual Studio,
FTP clients or MSBuild. You also can use continuous integration tools, such as Bitbucket, Hudson, or
HP TeamSite to automate build, test, and integration processes.
 Deployment slots. You can create two or more concurrently running versions of the same app hosted
on the same virtual machine. The execution environment of these concurrently running apps is
referred to as a slot. For example, you can create one slot for the production-ready version of your
web app, and then deploy your successfully tested and verified code into it. You then can create a
second slot intended for your staging environment and deploy the new version of your code to it to
run final acceptance tests. The staging slot will have a different URL. When the new version of your
staging-slot web app passes all the tests, you can quickly deploy it to production by swapping the
slots. Note that this approach also provides a straightforward rollback path. If the new version causes
unexpected problems, you can swap the slots once again to revert to the previous version of the
production code.
 Azure WebJobs. You can create scripts or compiled code and configure them as so-called WebJobs
to execute background processes. This allows you to offload from web apps time-consuming or I/O
bound tasks such as updating databases or archiving log files.
 Hybrid connections. You can implement hybrid connections from web apps to access on-premises
resources (such as Microsoft SQL Server databases) or virtual machines within an Azure virtual
network. By using the Hybrid Connection Manager, you can facilitate such connectivity without
opening any inbound ports on firewalls protecting your internal network.
Comparing the Web Apps feature, Azure VMs hosting websites, and
Azure Cloud Services
If you want to host a web application in Azure,
your three primary options are Infrastructure as a
Service (IaaS) Azure Virtual Machines (VMs), the
Web Apps feature of Azure App Service, or Azure
Cloud Services. The level of control, the flexibility
to scale, the amount of administrative overhead
you are willing to accept, and the programming
languages and frameworks that you want to use
will determine which of the three options is most
optimal.
Virtual machines
Because you have full control over the operating system on an Azure virtual machine, you can install any
web server software such as internet Information Server (IIS) or Apache. You can perform this installation
interactively through a Remote Desktop session or in an automated manner, for example by using VM
Agent extensions. In this case, implementation of web apps and their resulting functionality mirror your
on-premises environments. As a result, using the virtual machines option is most suitable in scenarios
where you want to migrate on-premises web applications into Azure with few or no modifications.
However, having full control over the operating system has also some potential disadvantages because
this requires you to invest time to update and maintain the Azure virtual machine. In addition, while the
Azure platform fully supports both the horizontal scaling and load balancing of Azure virtual machines,
implementing them is not as straightforward as with solutions based on PaaS.
Note: For more information regarding autoscaling of Azure virtual machines, refer to:
Module 3, “Virtual machines in Microsoft Azure” of this course. You will learn about load-
balancing of Azure virtual machines in Module 5, “Virtual networks.”
Web apps
Alternatively, you can choose to deploy your web apps by using the Web Apps feature. This involves
creating a web app instance and either uploading your own custom web application content or building
one by using content management systems such as Drupal, WordPress, or Umbraco. You can build
custom web applications by using ASP.NET, Node.js, PHP, and Python.
Note: With Web App on Linux, which is in public preview at the time of authoring this
content, you have support for Node.js, PHP, .Net Core, and Ruby application stacks.
Similar to Azure virtual machines, you can scale a web app vertically by changing its pricing tier.
However, unlike Azure virtual machines, which require a reboot, this change takes effect instantaneously.
This change increases or decreases the amount of computing resources allocated to that individual web
app instance to accommodate changes in the demand for its services. Alternatively, you can scale web
apps horizontally. Doing so increases or decreases the number of web app instances and relies on built-
in Azure load balancing to distribute incoming requests among them, which addresses fluctuating
demand.
Despite their agility and scalability, web apps are intended primarily for one or two-tier solutions where
the second tier provides a persistent data store. In addition, you do not have exclusive access, such as
through Remote Desktop Protocol, to the virtual machine that is hosting and running the web apps.
PaaS cloud services

The third option for implementing web apps in Azure relies on PaaS cloud services. An Azure PaaS cloud
service typically consists of a web role, with virtual machines hosting the application’s front end, and one
or more worker roles, with virtual machines handling background tasks. Virtual machines, in this context,
are referred to as role instances. You can scale each role independently by changing their pricing tiers
and the number of its instances.
PaaS cloud services combine the advantages of virtual machines and web apps. As a PaaS cloud service,
they eliminate the management overhead associated with IaaS-based solutions and they provide
additional control over their instances, including the ability to connect to them by using Remote
Desktop.
However, you should keep in mind that PaaS cloud services are unique to Azure. This means that for any
existing on-premises web apps, you need to modify them first before you can migrate them to the Azure
PaaS cloud services.
Note: The differences among the hosting models listed in the previous section become
less distinct as Azure services evolve. For example, Azure App Services include a Premium service
plan option, called Azure App Service Environment, intended for multitier applications.
Similarly, Azure IaaS virtual machine scale sets resemble Azure PaaS cloud services in many
aspects.
Creating and maintaining web apps

The first step in deploying a web app involves
creating an instance of a web app service. You
can accomplish this by using several different
methods. The most straightforward one is
available from the Azure portal interface.
To create a web app by using the Azure portal,
you need to specify the following settings and, for
some of them, accept their default values:
 App name. This is the first part of the URL
that you can use to access the website. This
name must be unique in the
azurewebsites.net Domain Name System
(DNS) namespace.
 Resource group. Similar to any other resource deployed by using Azure Resource Manager, a web
app instance must belong to one and only one resource group. You have the option of creating a
new resource group or using an existing one.
 App Service plan. This represents a set of functional and sizing characteristics of one or more
instances of the App Service, such as an instance size and horizontal scalability limits. In case of web
apps, this plan represents the support for a custom DNS domain in addition to the one in the
azurewebsites.net DNS namespace. By using an App Service plan, you can assign these
characteristics to a plan rather than assigning them to individual App Service instances. Doing so, in
turn, allows you to group multiple App Service instances, including web apps, mobile apps, API apps,
and logic apps, within the same plan and manage them together as a group. However, it is important
to be aware that modifying a service plan affects all of its App Service instances.
 Location. The definition of each App Service plan includes the Azure region where its App Service
instances reside. This implies that two web app instances hosted in two different regions cannot
belong to the same app service plan.
 Subscription. Similarly, each App Service plan exists within a specific subscription. As a result, you
cannot use the same App Service plan across multiple Azure subscriptions.
 Application Insights. This Azure-based service helps developers monitor and troubleshoot
performance and functionality of web apps. Application Insights relies on an additional
instrumentation software package that becomes part of your application. This additional software
does not significantly impact your web apps. It provides a variety of telemetry data that enhances
insight into web apps’ operational status and usage patterns.
Each Azure App Service plan is also linked to a pricing tier, which determines the cost of running its
instances. Of the five main service plans, three are further divided into several, differently priced
subcategories with matching functionality but different capacity.
Additional Reading: For App Service Plan Pricing Details, refer to: “App Service pricing” at:
http://aka.ms/Nmhpka
You can create a new service plan when you create a web app instance from the Azure portal. When you
create the service plan, you need to select an appropriate pricing tier and location and provide a name
that is descriptive, preferably. You can move apps that you create in one service plan into another if they
require different functionality or capacity. Alternatively, you can modify an App Service plan to meet the
demands of its web apps by changing the plan’s pricing tier.
Azure App Service supports five pricing tiers: Free, Shared, Basic, Standard, and Premium.
The Free plan

The Free App Service plan allows you to create a maximum of 10 web, mobile, logic, or API apps, and
limits each app to 1 GB of storage. The Free plan does not support custom domain names, which means
that every web app is accessible only by its name in the DNS domain azurewebsites.net. You cannot scale
out the Free tier apps across multiple instances, and they are not subject to any service level agreement
(SLA). Additionally, the outbound traffic for Free tier apps is limited to 165 megabytes (MB) per day.
The Shared plan

The Shared App Service plan does not impose a limit on the volume of outbound traffic and allows you
to use a custom domain name. However, you cannot use secure sockets layer (SSL) to secure access to
the Shared tier web apps by using these custom domain names. Similar to the Free tier, you cannot scale
the Shared tier apps across multiple instances and they do not qualify for any SLAs. The storage-capacity
limits are the same as the limits in the Free App Service plan. You can create up to 100 web, mobile, or
API apps, and up to 10 logic apps in the Shared App Service plan.
The Basic plan

The Basic App Service plan provides up to 10 GB of storage. Additionally, it allows you to use custom
domains with SSL encryption. The Basic tier apps qualify for the 99.95 percent uptime SLA, and you can
manually scale them up to three instances, with built-in Azure load balancers to distribute the load.
The Standard plan

The Standard App Service plan provides up to 50 GB of storage, and you can automatically scale out
apps to 10 dedicated instances. Up to five staged publishing slots are available for the Standard tier
apps. The service plan supports geo-distributed deployments and virtual private network (VPN) hybrid
connectivity.
The Premium plan

The Premium App Service plan enables enterprise-level capabilities. It provides up to 500 GB disk space,
supports automatic scalability of up to 50 instances, and allows you to create up to 20 staged publishing
slots.
Configuring and scaling web apps

The configuration settings that are available for
your web app depend to some extent on the
pricing tier of its service plan. The Azure portal
organizes these settings into the following
categories:
 General. This includes the web app
framework versions (Microsoft .NET, PHP,
Java, and Python), managed pipeline mode
(integrated or classic), platform (32-bit or 64-
bit), web socket support, and the Always On
support.
Note: The Always On feature, which is

available in the Standard and Premium pricing tiers, keeps web apps loaded in memory. Without
this feature, web apps are automatically unloaded from memory after a period of inactivity. By
default, this period is set to four minutes (although you can extend it to 30 minutes if you want
to maintain web apps in memory for a longer period of time when using a lower pricing tier of
web apps). Always On eliminates the delay associated with loading web app resources and code
into memory.
 Auto swap. Determines whether a web app you upload to a given staging slot is automatically
swapped with the production slot.
 Debugging. Allows you to enable and disable remote debugging from Microsoft Visual Studio 2012
and newer.
 App settings. Consist of arbitrarily defined key value pairs that you can reference within the web app
code.
 Connection strings. Contain information necessary to connect to external services, such as databases.
 Default documents. Constitute a list of webpages when browsing to the root URL of your website.
 Handler mappings. Designate specialized software components that handle processing of web app
files according to the file extensions.
 Virtual applications and directories. Define virtual directories and their relative paths within your
website.
In addition to configuration settings, two main scaling options are available for your web apps:
 The first option, referred to as scaling up, involves increasing the size of an individual web app
instance, including the number of central processing unit (CPU) cores and the amount of memory.
Scaling up might mean moving to a higher pricing tier, because of increased more resources
available to your web app.
 The second scaling option, referred to as scaling out, involves increasing the number of web app
instances, either manually or automatically. Manual scaling out is available starting with the Basic
tier. Automatic scaling can follow a custom schedule that you define. Alternatively, you can configure
a web app to scale automatically by setting a metric that will trigger provisioning of additional
instances when it reaches a specified threshold value. To support automatic scaling out, your web
app must be part of a Standard or Premium service plan.
Additional Reading: For more information about scaling web apps, refer to: “Scale up an
app in Azure” at: http://aka.ms/Peyuez
Note: With the Premium App Service plan, you can scale different web apps independently
within the same service plan. To learn more about per app scaling, refer to: “High density
hosting on Azure App Service” at: https://aka.ms/f9etc3
To configure scaling up 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. On the Choose your pricing tier blade, click the pricing tier that you want to scale up to, and then
click Select.
To configure scaling out 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 out (App Service Plan).
3. If this is the first time you are scaling out your App Service plan, click Enable autoscale. Depending
on the App Service plan, this will allow you to increase the number of instances either manually or
through autoscaling:
o When increasing the number of instances manually, specify the number of Instances that you
need.
o When autoscaling, specify the following settings:

 Autoscaling setting name. This is the name identifying the autoscaling settings.
 Resource group. This is the resource group containing additional Web app instances.
 Scale conditions. This is a collection of settings that determine scaling behavior. Each
condition includes a scale mode, which you can set to one of the following:
 Scale to a specific instance count. This mode allows you to specify the number of
instances that should exist if no other condition takes effect. Alternatively, you can assign a
custom schedule, including the start and end dates and times, that dictates when the
number of instances should increase to the value you provide.
 Scale based on a metric. This mode relies on a set of rules that you define, which
determine the appropriate number of instances dynamically, based on web app
performance, according to the values of metrics that you specify.
4. After you configured the scale-out settings, click Save to apply them to the App Service Plan hosting
your web app.
Another common web app custom configuration involves creating WebJobs. By using WebJobs, you can
configure custom scripts or executables to run background processes on the same virtual machine that
hosts the web app. You can configure WebJobs to run continuously, on demand, or on a schedule.
Note: While WebJobs are available in every pricing tier, using them reliably in a
continuous or scheduled manner requires enabling the Always On functionality. Because of this
requirement, the use of WebJobs is limited to the Basic, Standard, and Premium pricing tiers.
Demonstration: Creating and configuring a web app

 Create a new web app in Azure by using the Azure portal.
 Browse the new web app.

 View scaling and configuration options in the Azure portal.
Question: You work as a developer for your organization, and your manager wants you to
list the major benefits of using Azure App Service. What would you tell him?
Lesson 2
Deploying and monitoring web apps
After you have created your web app, you can create, publish, and deploy its content. You can use
several methods for deploying apps, such as Visual Studio, Visual Studio Team Services, Azure
Marketplace, and Microsoft WebMatrix. You also can use Web Deploy and FTP to create and upload apps
to host servers. After the apps are deployed, it is important to update and monitor the apps to ensure
consistent performance.
This lesson describes the processes for creating, publishing, and deploying web app content to web
apps. It also describes the options that you can use to monitor web app performance and operational
status.
Lesson Objectives
 Describe the options available for creating web app content.
 Explain how to publish web app content by using Visual Studio.
 Explain the staged deployment process of web apps.

 Describe how to monitor web apps.
Options for creating and publishing web app content

Creating a web app in Azure is the first step in the
process of creating a fully functional web app.
The remaining steps consist of building and
publishing its content.
You can use several methods to create and

publish web app content, including:
 Visual Studio. You can use Visual Studio to

write and deploy a variety of different types
of apps, including those for Windows Phone
and Windows Store, desktop apps, web apps,
and web services. You can write the app code
by using a number of programming
languages, including:
o Visual Basic
o Visual C#
o Visual C++
o Visual F#
o JavaScript
Visual Studio Team Services. You can use Visual Studio Team Services to develop and publish
website content to Azure web apps. It offers hosted source control, supports collaboration, and
implements a range of integration capabilities with Microsoft Azure.
Note: For more information about Visual Studio Team Services, refer to: “Visual Studio
Team Services” at: http://aka.ms/Yliikl
 Microsoft WebMatrix. This downloadable tool allows you to create, publish, and update web apps. It
supports a range of programming languages and provides a simple interface for website
deployment.
 The Azure Marketplace. You can use the Azure Marketplace to generate and publish content of a
web app while creating the web app. You can then select from a range of templates that best suit
the purpose of your web app, including:
o App frameworks such as Bottle, CakePHP, and Django
o Blogs including Ghost, WordPress, and Orchard CMS
o Forums such as phpBB and MonoX
o Galleries including Gallery Server Pro
o Tools such as BugNET, OpenX, and Open Web Analytics

Azure Marketplace also contains a wide range of web app templates geared toward specific business and
individual needs such as templates for websites of a coffee shop, a bakery, or a personal photo gallery.
As with web app code creation and publishing, you also have several choices for web app deployment,
including:
 File Transfer Protocol
 Synchronizing files and folders from a cloud storage service, such as OneDrive or Dropbox
 Web Deploy technology, which is included in Visual Studio, WebMatrix, and Visual Studio Team
Services
Web Deploy
Web Deploy is a technology that contains both client-side and server-side components that synchronize
content and configuration 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 to development,
staging, and production environments. We recommend using Web Deploy to deploy web app content
from Visual Studio to web apps in Azure.
Note that Web Deploy is available only when you use the IIS-based web servers. It offers a number of
advantages, including the ability to:
 Limit upload to only those files that have changed, which enables you to limit the network traffic
volume that results from updates to the existing content.
 Use the HTTPS protocol, which protects the content in transit and protects on-premises networks by
eliminating the need to open additional ports on firewalls.
 Secure the files at the destination by preserving their NTFS permissions.
 Deploy SQL Server databases by using custom SQL scripts.

 Modify the web.config file during deployment. For example, you can replace a database connection
string so that the web app that you deploy connects to a specific database.
MSDeploy.exe
Visual Studio and WebMatrix rely on the MSDeploy.exe command-line utility to carry out Web Deploy-
based operations. Alternatively, you can run MSDeploy.exe interactively from the Windows command
prompt or include it in a script or a batch file.
Additional Reading: To download the MSDeploy.exe tool, refer to: “Web Deploy 3.6” at:
http://aka.ms/D8g047
Using Web Deploy in Windows PowerShell

You also have the option of incorporating Web Deploy into Windows PowerShell scripts by running the
New-AzureRmResourceGroupDeployment cmdlet. This cmdlet uses Web Deploy to upload a Visual
Studio package or a project file to Azure, which lets you automate a web app deployment.
Deploying a web app by using FTP

FTP is an older protocol that is used frequently for uploading web apps to web servers.
FTP clients
You can configure a web app to accept FTP traffic, which allows you to upload your web app for
publishing. You will need to decide which FTP client to use in this case. Your options include:
 Web browsers. Most web browsers support FTP in addition to HTTP. You can use these browsers to
navigate through FTP sites and to upload content into them. However, browsers rarely support more
advanced features, such as retries following dropped connections.
 Dedicated FTP clients. Several dedicated FTP clients are available as a download, such as FileZilla,
SmartFTP, CoreFTP, and others. The advanced features in these browsers make them more suitable
for web app publishing, which can typically include several large file sizes.
 Integrated development environments (IDEs). Visual Studio and other IDEs support FTP for web app
publishing.
Configuring an FTP transfer

To publish a web app by using FTP, you must configure your FTP client with the destination URL of the
target web app and the credentials necessary to authenticate. You can find these credentials in the Azure
portal.
In addition, before you begin the transfer, you must select active or passive FTP mode. By default, FTP
uses active mode. In this mode, the client initiates the session and issues commands by using a
command port (usually port 21 on the server), and then the server initiates a data transfer by using a
data port (usually port 20 on the server). Firewalls might block these data transfers because they appear
as a separate communication. In passive mode, both commands and data transfers are initiated by the
client and are less likely to be blocked by firewalls.
Limitations of FTP
The principal advantage of FTP is its widespread use and its broad compatibility. However, FTP might not
offer more advanced features needed in such scenarios because it is an older technology that was not
designed specifically for uploading web app content. Some of the limitations include:
 FTP transfers files only. It cannot modify files or identify their purpose so you cannot automatically
alter the database connection strings in web.config files, as is possible when you use Web Deploy.
 FTP always uploads all files that you specify, regardless of whether they have been modified at the
target. This can potentially result in unnecessary data transfers and longer upload times.
Publishing a web app from Visual Studio

You can use Visual Studio to publish web apps in
Azure by following these high-level steps:
 Set up the development environment. To use

Visual Studio to publish your website
content, you must first install the Azure
Software Development Kit (SDK). Doing so
allows you to create Azure-specific projects
and interact with Azure services from within
the Visual Studio interface.
 Create your app. To create a web app in
Azure, start Visual Studio, and then click the
New Project option on the File menu. You
will be prompted to select the type of app that you want to create, such as an ASP.NET Web
application. The subsequent options that you must configure vary depending upon the type of app
you initially select but might include:
o Selecting Microsoft .NET Framework versions.
o Enabling Application Insights, which you can use to monitor web apps for availability and
performance.
o Specifying Authentication options, such as:
 No authentication
 Individual user accounts
 Organizational accounts
 Windows Authentication
o Choosing between Host in the cloud and Create remote resources. This option allows you to
create the web app during the publish process. It is enabled by default. If you enable it, you will
need to define the site name, region, and database options.
Note: It is not necessary for you to create a new web app in Azure before you develop and
publish the new web app by using Visual Studio. Visual Studio can create a new web app
automatically during the publishing process. Alternatively, you can choose to publish the web
app into an existing web app in Azure.
 Deploy the app to Azure. After you have created your app, you can publish it to Azure by using the
Publish Web Wizard. You must specify the target URL and credentials to authenticate.
 After you have published your web app, you might need to update its content periodically. You can
use Visual Studio to make any required changes and then republish the web app.
Additional Reading: For information on how to use Visual Studio to publish ASP.NET
websites on the Deploy an ASP.NET web app to Azure App Service by using Visual Studio
webpage, refer to: “Create an ASP.NET web app in Azure” at: http://aka.ms/C4mv1m
Performing staged deployments

After you deploy a web app to Azure, you might
need to update it occasionally. Developers add
new features and fix bugs to improve the
functionality and performance of an app. You can
deploy these changes in different ways,
depending on the location of your source code
and your deployment methodology.
If you use FTP for deployment, you simply upload

new files and overwrite them at the destination.
Note that FTP cannot identify updated content
automatically, so you should keep a record of the
modified files. Otherwise, you might need to
upload and overwrite all of the web app files. If you use Web Deploy, MSDeploy.exe compares the
content at the source and destination and then uploads only the modified files.
Continuous deployment
A relatively recent concept in the context of the software lifecycle, continuous deployment 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 implement continuous deployment, you need to perform the following steps:
1. Connect the project to a web app in Azure. In the Azure portal, you can configure the location of
your source code repository and provide credentials that Azure 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 perform a deployment.
Additional Reading: For more information on the configuration steps for a Git repository
in Visual Studio Team Services, refer to: “Continuous Delivery for Cloud Services in Azure” at:
http://aka.ms/A1pvoq
Deployment slots
Before you deploy the source code to a public-facing web app, you must test the code to validate its
integrity and reliability. Although you can perform much of this testing in the development environment,
the final testing location should be the staging environment in Azure. The staging environment should
match the production environment as closely as possible.
If you are using the Standard or Premium App Service plan to host your web apps, you can create two or
more deployment slots for each app. You can designate one of these slots as production and deploying
the fully tested code there. Any of the remaining slots can function as the staging environment. You then
have the ability to deploy web app updates to this staging slot and use it to perform acceptance tests.
Each slot has its unique URL.
When the new version in the staging slot passes all the tests, you can deploy it to production safely by
swapping the slots. This process also provides a simple rollback path. If the new version causes
unexpected problems, you can swap the slots one more time to switch back to the original production
version.
Best Practice: If you are using continuous deployment, you should never configure it to
deploy the code to a production slot. Doing so would result in deploying untested code in a
user-facing environment. Instead, you should configure deployment to a staging slot or a
separate web app, where you can perform final tests before final deployment.
When you swap a production and staging slot, the following settings in the production slot are replaced
with those of the staging slot:
 Handler mappings
 Monitoring and diagnostic settings
 WebJobs content
For staging, you typically run the web app against a dedicated staging database, which you designate by
using the connection string. If you want to switch to the production database following the swap, you
must edit the connection string in the production slot.
The following production slot settings will not change when you swap a staging slot into a production
slot:
 Publishing endpoints
 Custom domain names

 SSL certificates and bindings
 Scale settings
The remaining settings, including general settings, app settings, and connection strings, will change
during a swap by default. However, you can associate them to their current deployment slot, which will
preserve their existing configuration.
Staging slots are accessible from the internet, but considering that their URLs are not widely known,
random users are unlikely to find your staging site. However, 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 approved lists of IP addresses to the web.config file of the web app.
Monitoring web apps

Running web apps consumes resources, incurs
costs, and also can generate errors in response to
internal and external events. For example, a web
app might fail due to programming errors or
users might request webpages that do not exist.
Web apps in Azure provide visibility of their
behavior through monitoring and logging.
Monitoring web apps in the Azure

portal
The Azure portal includes a Monitoring lens (a
section within a blade) for each individual web
app. The lens contains a graph to which you can
add variety of performance counters that describe the operational status of your web app.
The available counters include:
 CPU Time
 Data In
 Data Out
 HTTP Server and Client Errors
 HTTP informational, success, and redirection events
 Requests
 Memory Working Set
 Average Memory Working Set
 Average Response Time
You can display the counters within a custom time range. You also can configure alerts to be distributed
through email or custom notification channels. Typically, you would use alerts to automatically notify
your team of administrators when there is a spike in demand or a performance issue. To add an alert,
perform the following steps:
1. In the Azure portal, navigate to the blade of the web app that you want to monitor.
2. On the Overview blade, click any of the graphs.
3. On the Metrics blade, click Add metric alert.

4. On the Add rule blade, in the Name text box, type a descriptive name.
5. In the Alert on drop-down list, click Metrics. Note that you also have the option to set an alert on
events.
6. In the Criteria section, accept the default settings in the Subscription, Resource group, and
Resource text boxes.
7. In the Metric drop-down list, click the metric to which you would like to add an alert.
8. In the Condition drop-down list, select a condition, such as Greater than.
9. In the Threshold text box, type the value that should trigger the alert.
10. In the Period drop-down list, select the period during which the value should exceed the threshold.
11. In the Notify via section, select Email owners, contributors, and readers.
12. Optionally, in the Webhook text box, type the HTTP/HTTPS endpoint that is capable of routing alerts
to other notification channels.
13. To finish creating the alert, click OK.
If you want to perform more in-depth troubleshooting, you might need the following diagnostics logs,
which you can selectively enable or disable:
 Detailed error messages. Records any HTTP response with a status code of 400 or greater, which
indicates an error.
 Failed request tracing. Logs detailed data describing the conditions when an error occurs. A trace
includes a list of all the IIS components that processed the request and the timing information.
 Web server logging. Enables the standard W3C extended log for your web app. This log shows all
requests and responses, client IP addresses, and corresponding timestamps assisting with assessing
server load, identifying malicious attacks, and studying the behavior of web app users.
 Application Logging. Collects diagnostic traces from the events generated by the web app code. To
record such events, its programmers must reference the System.Diagnostics.Trace class when they
develop the app.
Accessing diagnostic logs

You have the option of storing logs in the file system on the virtual machine that is hosting the web app.
If you choose this option, you can access the application and site diagnostic logs by using FTP or FTPS.
You can find the corresponding links in the Diagnostics logs blade in the Azure portal interface.
Alternatively, it is also possible to store logs in a designated Azure storage account.
Note: You will learn more about Azure storage accounts in Module 6, “Cloud storage.”
Question: What are the benefits of deployment slots, and how can you move your web app
between different slots?
Lesson 3
Creating and deploying PaaS cloud services
Azure provides two main categories of hosting options for applications: Infrastructure as a Service (IaaS)
and Azure Platform as a Service (PaaS) cloud services. In this lesson, you will see how the PaaS cloud
services differ from Azure App Services and Azure Virtual Machines. The lesson describes how you can
use the PaaS cloud services to create a modular, flexible, and highly scalable application architecture. You
will also see how to configure cloud services and deploy cloud service packages created by developers.
Lesson Objectives
 Describe Azure Cloud Services.
 Describe how to create a cloud service in Azure.
 Describe how to scale Azure Cloud Services.

 Deploy cloud services within Microsoft Azure.
What are cloud services?

Azure Virtual Machines allow you to install and
configure servers to run both stateful and
stateless applications in the cloud. Stateful
applications maintain their own state internally
while stateless applications rely on an external
data store. Azure App Services is a PaaS
implementation model that you can use to run
stateless applications and services without
maintaining underlying hardware, operating
systems, and web servers.
You can use the PaaS cloud services hosting

model to host web apps and web services. You
can build these web services with a more modular architecture than what the Azure App Services
provides. In particular, PaaS cloud services can divide the workload into web roles and worker roles. A
web role provides front-end functionality, while a worker role handles background tasks.
Similar to Azure App Services, PaaS cloud services allow you to scale out your applications to help ensure
fault tolerance and provide scalability. PaaS cloud services provide additional flexibility because you can
scale each role independently of other roles in the same cloud service. Despite this independence, you
can configure virtual machines that are hosting different roles to communicate directly with each other
within the same cloud service.
You can use an Azure storage account or a Microsoft Azure SQL Database instance to provide persistent
storage for virtual machines running web and worker roles. Doing this, in turn, allows you to facilitate
scenarios that require preserving the application state, which should not be stored directly within the
PaaS cloud services. Temporary storage services, such as Azure Storage queues or Azure Service Bus
queues, also provide a means for exchanging messages between web and worker roles.
Components and characteristics of an Azure PaaS cloud service

The following list defines the key characteristics and components of an Azure cloud service:
 Cloud service role. Consists of application and configuration files. A cloud service can have two types
of roles:
o Web role. Provides a dedicated IIS web server that hosts front-end web apps.
o Worker role. Provides compute resources for processes that handle asynchronous, long-running
tasks that require no user input or interaction.
 Role instance. A virtual machine on which your application code and role configuration run.
Note: A role can have multiple instances, defined in the service configuration file.
 Guest operating system. The operating system that is installed on the role instances (virtual
machines) that your app code runs on.
 Cloud service deployment. An instance of a cloud service deployed to Azure.
 Cloud service deployment components. To deploy an app as a cloud service in Azure, you need to
provide the following three components:
o A service definition file (with the extension .csdef) that defines the service model.
o A service configuration file (with the extension .cscfg) that provides configuration settings for
your cloud service and individual roles.
o A service package (with the extension .cspkg) that contains your app code and the service
definition file.
 Deployment environments. For cloud services, Azure offers two deployment environments, which are
functionally equivalent to the web app staging slots:
o A staging environment. An environment in which you can test your deployment before you
promote it to the production environment. In this environment, the value of the Globally Unique
Identifier (GUID) property of the cloud service identifies its URL (http://<GUID>.cloudapp.net).
o A production environment. The production environment hosts the version of the application
intended for its end users. Its URL is based on the DNS prefix that is assigned to your cloud
service during its creation, such as myservice.cloudapp.net.
Note: From the standpoint of a cloud service configuration, the two environments differ
only in the virtual IP (VIP) address and the corresponding DNS name by which each version of
the cloud service is accessed.
To promote a deployment in the staging environment to the production environment, just swap the
deployments. You do this by switching the VIP addresses for accessing the two deployments.
Maintenance and recovery

When you create an Azure PaaS cloud service, Azure maintains its virtual machines, including the
following tasks:
 Updates of the operating systems.
 Recovery from service and hardware failures.

Note: If you define at least two instances of every role, there is no interruption in service
when Azure PaaS cloud service performs the maintenance tasks, including your own service
upgrades.
Creating and deploying a cloud service

Developers create PaaS cloud service packages by
coding in an integrated development
environment (IDE) such as Visual Studio. The
Azure SDK includes emulators that can run web
roles and worker roles on developers’ computers
in an environment that closely matches Azure.
Before you can deploy a newly developed cloud
service package into Azure, you must first create a
new Azure cloud service.
Creating a PaaS cloud service

To create a PaaS cloud service in the Azure portal,
complete the following steps:
1. In the Hub menu on the left side of the portal, click +New.
2. On the New blade, click Compute, and then click Cloud service.
3. On the Cloud service (classic) blade, specify the following settings:
o DNS name. A unique name in the .cloudapp.net namespace
o Subscription. A target Azure subscription where the cloud service will reside
o Resource group. Create new or use existing
o Location. The target Azure region where the cloud service will reside
o Package. Optional because you can upload a package and a configuration file after the empty
cloud service container is created
o Certificates. Optional, but contingent on including a package, and allows you to secure web
traffic targeting the cloud service web role instances by using SSL
4. On the Cloud service (classic) blade, click Create.
Alternatively, you can create a PaaS cloud service by using the New-AzureService PowerShell cmdlet, as
shown in this example:
New-AzureService -ServiceName ‘CloudService’ -Location ‘East US’
Deploying service code

If you create an empty cloud service container, the next step involves deploying both the cloud service
package and the service configuration file that identify settings for the web and worker roles. Three
common ways to perform this deployment are:
 From Visual Studio, by using the Publishing Wizard. To simplify this deployment method, you can
obtain a publish profile from Azure and import it into Visual Studio. This method relies on 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,
ensure that untested code is not deployed accidentally to the production environment. Typically,
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 PaaS cloud service by using the Azure portal.
Deploying a cloud service

To deploy your cloud service from the Azure portal, follow these steps:
1. Click Browse and navigate to the Cloud services (classic) blade.

2. On the Cloud services (classic) blade, click the cloud service that you want to deploy.
3. On the cloud service blade, check the icon in the tool bar that designates the target deployment slot.
If its label is Production slot, then your deployment will target the production slot. To change the
target to staging, click Production slot, and then select Staging from the drop-down menu.
4. On the cloud service blade, click Upload.
5. On the Upload a package blade, specify the following settings, and then click OK:
o Storage account. Provides a hosting area where the uploaded package resides.
o Deployment label. Allows you to assign a descriptive deployment label that you can use to easily
distinguish among multiple deployments.
o Package. Points to the source location of the package file.
o Configuration. Points to the source location of the configuration file.

6. If cloud service roles will contain a single instance following the deployment, select the Deploy even
if one or more roles contain a single instance check box.
7. If you want to start deployment after the upload completes, select the Start deployment check box.
Note: Keep in mind that Azure can provide a 99.95 percent update SLA only if every role
has at least two instances.
8. Verify that the status for both the package and configuration file represented by the horizontal
green line underneath their respective text boxes indicates that the upload successfully completed,
and then click OK.
After you perform the steps above, your cloud service should be available in the production
environment.
Scaling a cloud service

One of the primary benefits of Azure PaaS cloud
services is their scalability. In general, you can
implement two types of scaling:
 Horizontal scaling. Involves changing the

number of instances in a cloud service role.
 Vertical scaling. Involves changing the size of

virtual machines that constitute instances of a
cloud service role.
In both types of scaling, your changes affect the

instances of the role that you specify. You can
scale individual cloud service roles independently
of each other.
You can access horizontal scaling settings from the Scale blade of your cloud service in the Azure portal.
If this is the first time you are scaling out your cloud service, click Enable autoscale.
Now you will be able to configure the following settings:

 Autoscaling setting name. This is the name identifying the autoscaling settings.
 Resource group. This is the resource group containing additional cloud service role instances.
 Scale conditions. This is a collection of settings that determine scaling behavior. Each condition
includes a scale mode, which you can set to one of the following:
o Scale to a specific instance count. This mode allows you to specify the number of instances
that should exist if no other condition takes effect. Alternatively, you can assign a custom
schedule, including the start and end dates and times, that dictates when the number of
instances should increase to the value you provide.
o Scale based on a metric. This mode relies on a set of rules that you define, which determine the
appropriate number of instances dynamically, based on their aggregate performance, according
to the values of metrics that you specify.
To perform vertical scaling of instances within a cloud service role, you need to update the cloud service
definition file, update the corresponding cloud service package, upload it into Azure storage, and deploy
it into the target Azure cloud service.
Demonstration: Creating, deploying, and scaling a cloud service

 Create a new cloud service.
 Configure the cloud service.
 Scale the cloud service.
Question: What scenarios do you consider to be most suitable for deployment of web apps
in Azure?
Lab: Web Apps and cloud services

Scenario
You were asked to deploy a blog for the Adatum Corporation public relations team and have decided to
use the Web Apps feature of Azure App Service for this purpose. Your internal development team has
also developed its first implementation of an Azure cloud service to replace a public-facing website
currently hosted on the premises. You want to test its deployment to Azure.
Objectives
 Create and configure a WordPress web app from the Azure Marketplace.
 Create and deploy a cloud service.
Lab Setup
User name: Admin
Password: Pa55w.rd

o User name: Admin
Exercise 1: Creating and configuring a WordPress web app

Scenario
Your users have suggested that they would like to post blog articles to a corporate website. You have
decided to host this website on Azure. In this exercise, you will create a website to host WordPress blogs
and then test the website by posting articles to the site.
Exercise 2: Creating a cloud service

Scenario
You need to create an Azure cloud service. You will use the Azure portal to complete this task.
Question: In the lab, you created an Azure cloud service. Which two files did you require to
create the cloud service?

Review Question
Question: From a management standpoint, what is the key difference between using a web app and an
Azure virtual machine with the IIS server role installed to host your web apps?
Best Practices
The Web Apps feature of Azure App Service is the primary choice for the majority of web apps for a
number of reasons:
 Both deployment and website management are integrated into the Azure platform.
 You can scale your sites rapidly to handle high-volume traffic.
 Web apps have the built-in support for load balancing.

 You can move your existing web apps to Azure quickly and easily with an online migration tool.
 You can use an open-source app from the Azure Marketplace or create a new site by using the
framework and tools of your choice.
Note that, in some situations, you might need a higher level of control over your web apps. For
example, you might require the ability to connect remotely to your server or to configure server
startup tasks. In such cases, Azure Cloud Services might be a better option. However, if such an
application requires significant modifications to run as an Azure cloud service, you might want
to consider using an Azure virtual machine to host it.
5-1
Module 5
Creating and configuring virtual networks
Contents:
Module Overview 5-1
Lesson 1: Getting started with virtual networks 5-2
Lesson 2: Configuring Azure networking 5-7
Lesson 3: Getting started with Azure Load Balancer 5-11

Lab: Create and configure virtual networks 5-14
Module Overview
Microsoft Azure virtual networks are a critical component to many Azure deployments. With Azure virtual
networks, you can establish secure and reliable communication among Azure virtual machines and also
between Azure virtual machines and a variety of other Azure services. You can also use them to extend
your on-premises datacenter to the cloud.
In this module, you will learn how to create and implement Azure networks and how to use their
components to enhance resiliency and availability of virtual machines.
Objectives
 Describe the purpose and functionality of Azure virtual networks.
 Create Azure virtual networks.
 Describe and implement Azure Load Balancer.

5-2 Creating and configuring virtual networks
Lesson 1
Getting started with virtual networks
In many aspects, Azure virtual networks resemble traditional, on-premises networks. However, when you
plan and deploy networking in Azure you need to consider some significant differences between them.
In this lesson, you will learn about the fundamental concepts of Azure virtual networks, the most
common needs they address, and their capabilities.
Lesson Objectives
 Describe virtual networks.
 Determine the need for a virtual network.
 Describe virtual network capabilities.
What are 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. As you might recall from
Module 3, “Virtual machines in Microsoft Azure,”
every new VM you create must reside on a virtual
network. You can have a virtual network that
contains only a single virtual machine. However, it
is more common to use virtual networks to
provide direct connectivity between two or more
Azure VMs. You can also connect different virtual
networks, to provide direct IP connectivity between 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.
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 a
sequence tasks you would perform when designing your on-premises networks. However, in this case,
you do not have to manage the underlying infrastructure. Instead, the networking features, such as
Domain Name System (DNS)–based name resolution and routing between subnets on the same virtual
network and to the internet, are automatically available. As the result, by default, every virtual machine
can access the internet.
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 VM network interface level. You will find out more about these
capabilities later in this module.
Determine the need for virtual networks

In general, and with regard to their virtual
network dependencies, Azure deployments will
belong to one of these three categories:
 Cloud-only deployments
 Cross-premises deployments
 Deployments without dependencies on

virtual networks
In cloud-only deployments, you need to provision

one or more virtual networks in Azure. With
cross-premises deployments, you must
additionally establish connectivity between virtual
networks in Azure and your on-premises environment. You might also encounter a fair number of
deployments that do not have any virtual network dependencies. This includes, for example, deploying
services which are not virtual network aware, such as Azure SQL Database.
Azure VMs provisioned by using the Azure Resource Manager deployment model must reside on a
virtual network. This means you must implement one or more virtual networks either prior to or during
your Azure VM deployment.
Platform as a service (PaaS) cloud services support direct virtual network connectivity, but do not require
it. As a result, you can deploy a PaaS cloud service without creating a new virtual network or using an
existing one. On the other hand, you might choose to use a virtual network to provide direct
communication between web and worker roles of a PaaS cloud service and Azure VMs. However,
remember that Azure VMs deployed by using the Azure Resource Manager deployment model cannot
coexist on the same virtual network with PaaS cloud service web and worker roles. This is because PaaS
cloud services use classic virtual networks. To provide direct connectivity in this scenario, you must
connect the classic virtual network hosting PaaS cloud service with the Azure Resource Manager virtual
network hosting Azure VMs. If both networks reside in the same Azure region, you can accomplish this
by using VNet peering. If the networks are in different Azure regions, you can establish connectivity by
creating a virtual private network (VPN) connection between them.
The Web apps feature of Azure App Service also supports integration with the Azure virtual networks to
facilitate direct connectivity to Azure VMs. Such integration is based on a point-to-site VPN connection
between an individual Web app and the target virtual network.
To allow direct connectivity between your on-premises systems and Azure virtual machines, you need to
create a VPN tunnel over the internet or provision a private circuit.
Note: Whenever you need to connect two Azure virtual networks or establish cross-
premises connectivity, ensure that none of the networks have overlapping IP address spaces.
Always take this into account as part of your Azure virtual network design.
Some Azure services, such as Microsoft Azure SQL Database or Microsoft Azure Active Directory, are not
virtual network–aware. Deploying these services is not dependent on the presence of Azure virtual
networks.
Virtual network capabilities
IP Address allocation
The Azure platform relies on Dynamic Host
Configuration Protocol (DHCP) for allocating IP
addresses to Azure VMs that reside on a virtual
network. A virtual machine will retain an IP
address allocated by DHCP indefinitely. It is
released if you delete the VM or place it in the
Stopped (Deallocated) state. Typically, the virtual
machine enters this state when you stop it either
from the Azure portal or by using Azure
PowerShell or Azure command-line interface
(CLI). If you want a virtual machine to retain a specific IP address regardless of its state, you should
configure this IP address assignment as static.
Note: When you want to assign a static IP address to computers in an on-premises

environment, you should configure it within the operating system. Do not use this method for
Azure virtual machines, however, because this will result in dropped connections and
connectivity failures. Instead, use standard Azure management tools and interfaces. You can
configure a static IP address for a virtual machine by using the Azure portal, Azure PowerShell,
Azure CLI, or Azure Resource Manager templates (when using Azure Resource Manager
management model).
Note: Every Azure VM has at least one network interface card (NIC). The number of NICs
supported by an Azure virtual machine depends on its size. Every NIC has at least one private IP
address. As you might recall from Module 3 of this course, you can also allocate a public IP
address to the same network interface to facilitate direct internet connectivity to the VM. You
can also configure that IP address as static to ensure that it does not change when the Azure VM
transitions to the Stopped (Deallocated) state.
User-defined routes
User-defined routes allow you to modify the default routing behavior in Azure virtual networks. First you
define one or more routes that consist of the IP address range designating the intended destination of
IP-based traffic. Then you define an IP address that represents the next hop on the route to that
destination, and assign this route to the subnet from which the traffic originates.
Forced tunneling
Forced tunneling is a specific use case of a user-defined route. In this case, 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.
Traffic filtering
You can implement collections of firewall rules, referred to as Network Security Groups (NSGs), that you
can associate with virtual network subnets. If you need more granular control, you also have the option
of assigning them to network adapters of virtual machines.
You can use NSGs to provide network-based segmentation of Azure resources by defining rules that
allow or deny specific traffic to specific virtual machines or subnets. Doing so enables you to implement
isolated subnets that are equivalent to perimeter networks in on-premises environments.
Load balancing
Virtual networks support internal load balancers. These load balancers allow you to distribute incoming
traffic across Azure VMs residing on the same virtual network subnet. You can also use external load
balancers to distribute traffic originating from outside Azure in the same manner. For example, by
applying this approach to three VMs running the same web app, you can distribute incoming traffic
across all of them. This will ensure that if one of them fails, the remaining two will handle all incoming
requests automatically.
If you want to implement TCP/UDP-based load balancing across Azure VMs, you can use Azure Load
Balancer, which is part of the platform’s built-in capabilities. To provide load balancing on the application
layer, you can implement an Azure Application Gateway, which handles HTTP-based network traffic.
Azure Application Gateways support more advanced scenarios not available with Azure Load Balancer,
such as Secure Sockets Layer (SSL) processing offload, cookie-based session affinity, and URL path–based
routing. They also offer enhanced security by including Web Application Firewall capabilities.
Note: You will learn more about Azure Load Balancer in the third lesson of this module.
DNS
DNS facilitates resolving user-friendly fully qualified domain names (FQDNs), such as www.adatum.com,
to the corresponding IP addresses. Azure automatically provides a built-in DNS service to all VMs that
reside on a virtual network. This mechanism allows VMs to communicate with each other by using their
hostnames and to resolve internet domain names. However, in some cases, you might need to
implement your own DNS server. For example, you might want to provide name resolution in cross-
premises scenarios (that is, to resolve the names of your on-premises computers from Azure virtual
machines and vice versa). Also, you might assign a custom DNS domain name to Azure VMs (for
example, when deploying Active Directory domain controllers by using Azure VMs).
Virtual network connectivity

By default, computers outside of a virtual network cannot connect to Azure VMs hosted on an Azure
virtual network via their private IP addresses. However, you can implement such connectivity. If these
computers reside outside of Azure, 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, which connects Azure virtual networks within the same Azure region.
 VNet-to-VNet connection, which connects Azure virtual networks regardless of region. This is similar
to a site-to-site VPN. However, in this case, cross-region traffic does not traverse the internet but is
routed over the Microsoft Azure backbone network.
Any VPN-based method requires provisioning a VPN gateway in the Azure virtual network for which you
want to establish connectivity. The VPN gateway handles routing of network traffic in and out of the
virtual network.
Note: While you can use either VNet peering or VNet-to-VNet connection to connect two
Azure virtual networks in the same Azure region, we recommend using VNet peering. This
method delivers better performance and does not require you to provision VPN gateways. In
addition, if both virtual networks must be accessible from your on-premises locations, a peered
virtual network provides the added benefit of support for routing cross-premises traffic via a
VPN gateway. This allows you to use a single VPN gateway on one of the virtual networks, rather
than deploying a VPN gateway on both.
You can create and configure Azure virtual network by using the Azure portal, Azure PowerShell, Azure
CLI, or Azure Resource Manager templates. By default, you can create up to 50 virtual networks per
region within the same subscription, although you have the ability to increase this limit to 100 by
contacting Azure support. Virtual networks are free of charge, but some of their resources, such as VPN
gateways, incur extra cost.

Question
Which of the following Azure services support direct connectivity to an Azure virtual network?
Azure SQL Database
Azure Active Directory
Azure Virtual Machines
Azure PaaS Cloud Services
Web Apps
Lesson 2
Configuring Azure networking
To create and use a virtual network, you must first designate its IP address space and allocate one or
more IP address subnet ranges within it. Then you can take advantage of the virtual network capabilities
described in the first lesson of this module. In this lesson, you will learn how to create virtual networks
and implement different networking components that leverage virtual network capabilities. You will also
learn about Azure networking components that do not depend directly on Azure virtual networks.
Lesson Objectives
 Describe virtual network components.
 Create a virtual network.
 Describe Azure networking components that do not depend directly on Azure virtual networks.
Creating and configuring Azure virtual networks

To provision an Azure virtual network, you must
configure several of its components. In this topic,
you will focus on the cloud-only scenario. Cross-
premises scenarios are more involved, requiring
you to provision a virtual gateway and either
establish either a VPN tunnel or provision an
ExpressRoute circuit to your on-premises
infrastructure.
Each virtual network resides in a specific Azure

region (referred to as Location in the Azure
portal interface). The region dictates the location
of Azure VMs that you subsequently deploy into
the virtual network. After you create a virtual network, changing the region associated with it is not
possible.
Note: Azure virtual networks cannot span multiple Azure regions.
In addition to choosing the Azure region, you must also specify the scope of IP addresses that will be
automatically assigned to virtual machines that you deploy into that virtual network. While the scope of
IP addresses can include public IPv4 ranges, an overwhelming majority of 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 together if you want to do so later.
Note: While we introduce the concepts of Azure virtual networks in the context of Azure
VM deployments, keep in mind that other services (such as load balancers, VPN gateways, or
application gateways) also reside within its boundaries. These services also follow the general IP
addressing rules described in this topic. You will learn more about them later in this module.
Similar to your on-premises environment, within an Azure virtual network, you can implement logical
segmentation by dividing its IP address space into multiple subnets. Subnets partition the virtual network
into smaller IP ranges, providing the ability to secure resources within them. For example, when
implementing a multi-tier solution consisting of several sets of virtual machines, it typically makes sense
to place each tier on a separate subnet. Doing so allows you to restrict traffic between tiers by
implementing Network Security Groups (NSGs).
Within each subnet, the first four IP addresses (including the network IP address) and the last IP address
are reserved for internal use. The smallest subnet you can create in Azure has the 29-bit subnet mask
(yielding 3 usable IP addresses). You can easily move virtual machines across subnets within the same
virtual network.
Note: You cannot move Azure VMs between virtual networks. If you need to place an
Azure VM on a different virtual network, you need to redeploy it.
Another functionality that you can configure within a virtual network is its DNS name resolution. You can
choose the name resolution that Azure provides internally, which is automatically available on each
virtual network. Alternatively, you can choose a custom DNS name resolution, which requires that you
provide IP addresses of one or more DNS servers that will handle name resolution. These servers can
reside within the same Azure virtual network (as is frequently the case when deploying Active Directory
domain controllers in Azure virtual machines), in your on-premises environment (if it is a cross-premises
scenario), or on the internet.
Demonstration: Creating a virtual network

In this demonstration, you will learn how to create an Azure virtual network.
Azure networking features

In addition to virtual network capabilities covered
in the first lesson of this module, Azure offers
some networking features that do not depend
directly on Azure virtual networks. This topic
provides an overview of these features.
Public IP addresses
If you need to allow direct access from the
internet to an Azure virtual machine or an Azure
Load Balancer, you need to assign a public IP
address to them. This IP address belongs to the
pool of public addresses associated with the
Azure datacenter where the VM or the load
balancer resides. As with private IP addresses, public IP addresses are allocated dynamically, by default.
To ensure that the public IP addresses do not change, configure the public IP assignment as static.
However, you cannot choose a specific IP address as you can with private IP addresses. Instead, an
available IP address from the public pool is automatically assigned to the virtual machine and remains
the same for the lifetime of the VM or the load balancer.
Azure Traffic Manager

Azure Traffic Manager provides the third type of load balancing solution, available natively in Azure.
Unlike the other two types (Azure Load Balancer and Application Gateway), its load balancing mechanism
is based exclusively on DNS name resolution. This mechanism intelligently directs access requests across
multiple, instances of an application running in different locations based on one of the following
algorithms that you specify:
 Performance. Traffic Manager evaluates which application instance is closest to the end user (from
the standpoint 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. If the
instance does not pass Traffic Manager health checks, the DNS name of the next application instance
(in the prioritized list of instances that you define) is returned to end users.
 Weighted. Traffic Manager provides DNS names of every application instance (alternating among
them). The distribution pattern depends on the value of the weight parameter that you define. In
particular, the volume of traffic requests that Traffic Manager directs to a particular instance is
directly proportional to its weight.
 Geographic. Traffic Manager directs traffic to a specific location based on the geographical area from
which an access request originates. This allows you to provide localized user experience and restrict
access to comply with data sovereignty rules.
Traffic Manager periodically checks all instances of the application that it manages. If an instance does
not pass the checks, it is taken out of the distribution until the next successful check.
Note: Note that Traffic Manager supports applications external to Azure, if they are
accessible from the internet and have publically resolvable DNS names.

Question
What is the smallest subnet that you can implement in an Azure virtual network?
/24
/26
/29
/30
/31
Lesson 3
Getting started with Azure Load Balancer
Azure Load Balancer provides functionality frequently implemented in on-premises network
environments by using software and hardware load balancers. In this lesson, you will learn about the
primary features of Azure Load Balancer and how to implement them.
Lesson Objectives
 Describe principles of Azure Load Balancer.
 Deploy a load balancer in an Azure virtual network.
Overview of Azure Load Balancer

Azure Load Balancer provides functionality
equivalent to typical hardware and software load
balancers by eliminating single points of failure
(both on the application or hardware level) and
ensuring continuous uptime during planned
maintenance events or upgrades of virtual
machine workloads.
Azure Load Balancer

There are two types of Azure Load Balancer:
 Internal. Enables you to load-balance network
traffic targeting one or more private IP
addresses.
 Internet-facing. Enables you to load-balance incoming internet traffic targeting one or more public
IP addresses.
In both cases, you can balance traffic that targets specific IP addresses and specific Transmission Control
Protocol (TCP) or User Datagram Protocol (UDP) ports. In addition, you can use Network Address
Translation (NAT) rules to facilitate connectivity to specific ports on individual Azure VMs behind the load
balancer.
Internal load balancer

An internal load balancer allows you to run highly available services behind one or more private IP
addresses. You can use internal load balancer to load balance the types of traffic originating from:
 Virtual machines on the same virtual network (for example, between separate tiers of a multi-tier
application, where Azure VMs in separate tiers reside on separate subnets).
 Virtual machines on another virtual network connected via a VNet-to-VNet connection or VNet
peering.
 On-premises networks in cross-premises scenarios with connectivity via site-to-site VPN or

ExpressRoute.
Internet-facing load balancer

Internet-facing load balancers distribute traffic that targets one or more public IP addresses assigned to
the load balancer. Just as with an internal load balancer, Incoming traffic is subject to the load balancer
rules and inbound network address translation (NAT) rules that determine its distribution across the
Azure VMs in the back-end pool. Traffic is then delivered to the network interface card (NIC) attached to
one of the backend VMs.
Creating an Azure load balancer

Creating an Azure load balancer involves
configuring the following settings:
 Frontend IP configuration. This setting

specifies one or more static or dynamic IP
addresses that will accept incoming traffic.
 Backend pool. This setting identifies the

Azure VMs that will accept incoming traffic.
Incoming traffic will be either distributed
across these virtual machines in a load-
balanced manner or, if it is a subject to a NAT
rule, delivered to a specific Azure VM.
 Load balancing rules. This setting consists of one or more rules that dictate load-balancing behavior.
Each rule designates a protocol, a port, a corresponding backend pool, and a backend port where
the load balancer should deliver load-balanced traffic. In addition, each rule must also contain the
following parameters:
o Probe, which represents an HTTP-based or TCP-based test that the load balancer performs to
determine whether Azure VMs in the backend pool are healthy.
o Session persistence, which allows you to specify that the load balancer should redirect traffic
originating from the same IP address (and over the same protocol, if preferred) to the same
backend pool VM.
o Idle timeout, which determines the maximum amount of time an idle TCP or HTTP connection
will remain open.
o Floating IP, which is intended for scenarios where the load balancer serves as a SQL AlwaysOn
Availability Group listener.
In addition, you can optionally configure inbound NAT rules. You can use a NAT rule to target a specific
VM in the backend pool when receiving incoming traffic on a specific port (rather than load balance it
across all VMs in the pool).
You configure these settings for both an internal and an internet-facing load balancer. The primary
difference between them is that the Frontend IP configuration references a private IP address for an
internal load balancer and a public IP address for an internet-facing load balancer. In addition, an
internet-facing load balancer provides support for IPv6.
Demonstration: Creating an Azure load balancer

In this demonstration, you will see how to create an Azure load balancer.
Question: Is it mandatory to set up a custom Domain Name System (DNS) on your Azure
virtual network?
Lab: Create and configure virtual networks

Scenario
A. Datum Corporation plans to deploy a number of Azure virtual machines that will need direct network
connectivity. You need to create virtual networks to allow for direct communication between them.
Objectives
 Create virtual networks.
 Test network connectivity.
Lab Setup

User name: Admin
Password: Pa55w.rd
o User name: Admin
Exercise 1: Creating virtual networks

Scenario
You start by creating a new virtual network by using the Azure portal.
Results: After completing this exercise, you should have created a new Azure virtual network by using
the Azure portal.
Exercise 2: Verifying virtual network functionality

Scenario
After creating the Azure virtual network, you want to deploy two virtual machines into it and ensure that
they can communicate directly by using their private IP addresses.
The main task for this exercise is as follows:
1. Prepare for the next module.
 Task 1: Prepare for the next module

 When you are finished with the lab, do not revert the virtual machines. Please keep all of the VMs
running. The VMs in their current state are required for the next module.
Results: After completing this exercise, you should have:
Deployed two Azure virtual machines into an existing Azure virtual network by using the Azure portal.
Verify direct network connectivity between the two virtual machines on the same Azure virtual network.
Question: Can you move virtual machines that you created in the lab to a different virtual
network?
Question: Will you be able to successfully ping the two virtual machines on the virtual
network?

Review Question
Question: If you decide to implement some of your services on the Azure platform, would
you need to create Azure virtual networks?
6-1
Module 6
Cloud storage
Contents:
Module Overview 6-1
Lesson 1: Understanding cloud storage 6-2
Lesson 2: Create and manage storage 6-9
Lab: Configure Azure Storage 6-15

Module Overview
The Microsoft Azure platform includes Microsoft Azure Storage, which provides a persistent and resilient
location for storing Azure virtual machines’ (VMs) virtual disk files. Additionally, it can host tables and
queues, including emulating on-premises file servers. In this module, you will learn about these
capabilities.
Objectives
 Describe the features and benefits of cloud storage.
 Create and manage storage in Azure.

6-2 Cloud storage
Lesson 1
Understanding cloud storage
Before you implement and use Azure Storage, it is important to familiarize yourself with the range of
cloud-storage services and their characteristics. There are several cloud-storage options available, each
of which is optimized for specific usage scenarios. The purpose of this lesson is to present and compare
these options.
Lesson Objectives
 Describe Azure Storage.
 Describe the Microsoft Azure Blob storage option.
 Describe the Microsoft Azure Table storage option.
 Describe the Microsoft Azure Queue storage option.

 Describe the Microsoft Azure File storage option.
 Describe storage-replication options.
 Compare storage options.
Overview of Azure Storage

Azure Storage is a highly scalable service that you
can use to store large amounts of data, including
structured data (rows of key-value pairs) and
unstructured data (media or virtual disk files).
Developers and cloud architects commonly
choose Azure Storage to host data for the Web
Apps feature of the Azure App Service and the
platform as a service (PaaS) cloud service. IT
professionals who deploy infrastructure as a
Service (IaaS) VMs rely on Azure Storage for
storing VM operating systems and data disks, and
for hosting network-accessible shared content.
Azure Storage is a managed service that you can provision as needed and use across a variety of
platforms, services, and applications. These typically include other Azure Storage-resident services that
rely on storage, but you also have the option of accessing Azure Storage from your on-premises
locations or any internet-connected system. All Azure services, including storage, are based on a REST
API over HTTP/HTTPS. This allows you to make calls from your code to that API.
Azure Storage offers four types of storage services, designed for different content types, including:
 Blob (binary large object) storage. This option is ideal for nonstructured text or binary data, including
media files or virtual disk files. There are three types of Blob storage:
o Page blobs, which you use most commonly for virtual disk files.
o Block blobs, which offer performance advantages for media content.
o Append blobs, which are ideal for storing logs.

 Table storage. This option is a structured data store that you can use to host rows of key-value pairs
of data, or NoSQL data types.
 Queue storage. This option provides a temporary store for relatively small messages that
applications or individual application components exchange so that they can communicate.
 File storage. This option allows you to host shared content that is accessible by using the Server
Message Block (SMB) protocol. This enables you to implement file-sharing functionality in a manner
similar to the one that traditional Microsoft Windows or Samba file servers provide in on-premises
environments.
You will learn more about each of these Azure Storage types in this lesson’s upcoming topics.
Storage accounts
You organize Azure Storage by using storage accounts, which are logical groupings of individual storage
types. Additionally, Azure Storage enforces limits on size and the input/output (I/O) throughput for data
that you place in it.
To use Azure Storage, you first need to create a storage account. However, this is a soft limit, which you
can increase by opening a service ticket with Azure support.
There are two types of Azure Storage accounts that you can create:
 General purpose storage accounts. These accounts support all four types of storage, including the
three types of Blob storage. However, this is subject to the performance tier that you select, and
these tiers can include:
o Standard. This performance tier allows you to store up to 500 terabytes (TB) of content,
including any combination of blobs (page, block, or append), tables, queues, and files. This tier
relies on traditional hard disk drives, which dictate its I/O throughput and latency characteristics.
o Premium Storage. This tier allows you to store up to 35 TB of virtual disk files (page blobs). This
tier relies on solid state drives (SSDs), delivering performance sufficient to accommodate the
most demanding workloads.
 Blob storage accounts. These accounts are capable of, and optimized for, storing block blobs and
append blobs only. Blob storage accounts support two access tiers:
o Hot blob storage. This tier is for content that you access frequently, and has lower costs
associated with the I/O storage transactions, but higher cost per gigabyte (GB) of storage used.
o Cool blob storage. This tier is for content that you access infrequently, and has higher costs
associated with the I/O storage transactions, but lower cost per GB of storage used.
The Azure platform protects access to storage accounts by using the combination of the storage account
name and two keys that are auto-generated during storage account creation. Having two keys allows you
to change the keys periodically without disrupting existing connectivity. The key change involves
providing access to a storage account with one key while modifying the other account. When you
complete this step, you can access the next storage account with the other key and also modify the first
account.
Each storage account within an Azure subscription has its limitations and constraints. Before you
implement Azure Storage, we recommend that you read the current documentation and learn about
these limitations.
Additional Reading: For more information, refer to: “Azure subscription and service limits,
quotas, and constraints” at: http://aka.ms/O5vvrr
6-4 Cloud storage
What is Blob storage?

There are three types of Blob storage:
 Page blobs. This storage type is optimized for

random read and write operations, due to
their page-based structure. Each page is 512
bytes in size and represents the scope of an
individual storage operation. Most
commonly, people use this type of blob to
store virtual hard drives for VMs. The
maximum size of a page blob is 8 TB.
 Block blobs. This storage type is optimized
for streaming audio and video, due to their
block-based structure. A block ID identifies
each block from a single blob, and it can include an MD5 hash of its content. When you upload a
large file to a block blob, the resulting blob is divided into blocks of up to 100 megabytes (MB) in
size, which Azure uploads concurrently and then combines into a single file. This results in a faster
upload time. Additionally, when you need to modify data, you can modify blob data at the block
level by replacing existing blocks. A block blob can consist of up to 50,000 blocks of 100 MB each in
size, which yields the maximum size of approximately 4.75 TB.
 Append blobs. This storage type is for append operations, but does not include support for
modifying existing content. This type of blob is useful for storing logging, monitoring, or auditing
data.
Note: Please note that you can choose the type of a blob storage only when you create a
blob. It is not possible to convert one blob storage type to another.
To organize blobs in a storage account, we recommend that you create one or more containers, which
are equivalent to file-system folders, and have the blobs correspond to the files within them. You cannot
nest these folders, so they are only one level deep. If you want to emulate multilevel folder hierarchy
within a container, you can include multiple “\” characters in the name of blobs that reside in the same
container.
You can access each blob by using its unique URL in the following format:
https://<storageaccountname>.blob.core.windows.net/<containername>/<blobname>
Microsoft provides several software development kits (SDKs) that developers can use for
programmatically working with Blob storage. At the time of writing this course, we support the following
languages and platforms:
 .NET
 C++
 Java
 PHP
 Node.js
 Ruby
 Python
 iOS
 Xamarin
What is Azure Table storage?

The term table, in the context of Azure and Azure
Table storage, describes a group of entities. An
entity is a collection of properties (also referred to
as keys) and values stored together in the table.
You can define up to 252 custom properties;
however, each table also contains three system
properties:
 Partition key. This system property allows you

to group multiple rows together based on
the common property value assigned to each.
 Row key. This system property uniquely

identifies each row within its partition
(effectively, the combination of the row key and the partition key uniquely identifies each row in the
entire table).
 Time stamp. This system property optimizes table updates.

At a high level, this type of storage is somewhat similar to a database or a Microsoft Excel spreadsheet
because its tables consist of collections of rows (entities) and supports manipulating and querying the
data contained in the rows. However, entities that co-exist in the same Azure table do not necessarily
have the same structure or the same schema. The absence of the consistent schema is one of the
differences between Azure Table storage and relational databases. Another distinction is that there is no
support for relations between tables. This is why Azure Table storage is sometimes described by using
the term NoSQL storage. In addition, Azure tables have limited indexing capabilities. A table contains
only a single clustered index based on the combination of the partition key and the row key.
Table storage can accommodate any number of tables, up to the total capacity of 500 TB per storage
account. The largest entity can contain up to 1 MB of data.
Storing and accessing data in Azure Table storage typically involves using programmatic methods. Most
applications use client libraries or call the REST API directly. Each table is accessible via its unique URL in
the following format: https://<storageaccountname>.blob.core.windows.net/<tablename>.
6-6 Cloud storage
What is Queue storage?

Azure Queue storage provides a mechanism for
applications and services to pass messages to
each other asynchronously. You can use Queue
storage to provide temporary storage for large
volumes of messages that you can access from
any location via authenticated calls over the HTTP
or HTTPS protocols.
A storage account can contain an unlimited

number of queues, up to the total capacity of 500
TB per storage account. Individual messages are
limited to 64 kilobytes (KB), with the total number
limited only by the total capacity of the storage
account, which means that a single queue can contain millions of messages.
A common scenario that relies on Queue storage involves passing messages from a web role to a worker
role of an Azure cloud service. A web role is usually a website or web application. A worker role is
typically a service or process that manages background processing tasks.
Queues can be addressed by using the following URL format:

https://<storageaccountname>.queue.core.windows.net/<queuename>.
What is File storage?

Similar to block blobs, Azure File storage provides
the ability to store unstructured files. However, in
addition to supporting access via the REST API
(including .NET, Java, and Python), it also
facilitates access via the SMB protocol (in
particular, both SMB 2.1 and SMB 3.0). In
addition, rather than using containers to store
files, File storage allows you to create shares and
a multi-level folder hierarchy within them. This
enables File storage to emulate file sharing, which
is equivalent to that implemented by using on-
premises Windows and Samba file servers.
As a result, you can connect to the https://<storageaccountname>.file.core.windows.net/<sharename>
Azure File storage share by using the net use command. To do this, you must specify the target storage
account and its share, in addition to establishing a security context for the connection (by providing the
storage account name and one of two storage account keys), as shown below:
net use <driveletter>: \\<storageaccountname>.file.core.windows.net\<sharename>

/u:<storageaccountname> <storageaccountkey>
Storage replication options

To ensure resiliency and availability, Azure
automatically replicates the content of a storage
account across multiple physical servers. There
are four replication schemes:
 Locally redundant storage. Your data

replicates synchronously across three copies
within a single facility in a single region.
Locally redundant storage protects your data
against server hardware failures but not
against a failure of the facility itself. This is
the only option available for general-purpose
Premium Storage accounts.
 Zone-redundant storage. Your data replicates synchronously across three copies that reside in two
or three facilities in a single region. Zone-redundant storage offers more resiliency than locally
redundant storage; however, it does not protect against failures that affect an entire region. More
importantly, zone-redundant storage is available only for block blobs in general-purpose storage
accounts, which makes it unsuitable for hosting IaaS VM disk files, tables, queues, or file shares.
 Geo-redundant storage. 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, Azure
Storage automatically fails over to the secondary region. Effectively, geo-redundant storage offers
superior resiliency over locally redundant storage and zone-redundant storage.
 Read-access geo-redundant storage. As with geo-redundant storage, your data replicates

asynchronously across two regions and synchronously within each region, yielding six copies of a
storage account. However, with read-access geo-redundant storage, the storage account in the
secondary region is available for read-only access regardless of the primary region’s status.
Compare storage options

As explained in previous topics, Azure Storage
provides different types of storage. In general, the
storage type that is optimal for you depends on
the scenario that you intend to implement. Some
of the more common usage scenarios for the
different types of storage include:
 Blob storage:
o Storing virtual hard disk files for Azure

VMs as page blobs in general-purpose
storage accounts (with either Standard or
Premium Storage performance tier).
Note: It is not possible to implement Azure VMs with their virtual hard disk files stored in a
Blob storage account (since Blob storage accounts support block blobs and append blobs only).
6-8 Cloud storage
o Hosting frequently accessed content for Web Apps as block blobs in the hot blob storage access
tier of Blob storage accounts.
o Archiving infrequently accessed data as block blobs in the cool blob storage access tier of Blob
storage accounts.
o Preserving incremental dumps of application or security logs (e.g., for compliance reasons) in
append blobs in the cool blob storage access tier of Blob storage accounts.
o Storing SQL Server database files directly in an Azure Storage account as page blobs.
o Backing up SQL Server databases directly into page or block blobs in an Azure Storage account.
 Table storage:
o Inexpensive storage of large amounts of structured but non-relational data for application usage
or analysis.
o Hosting data sets that do not require joins, foreign keys, or stored procedures and that can be
de-normalized and accessed efficiently by using a single clustered index.
 Queue storage:
o Passing messages between applications or between components of the same application.
o Graceful handling of bursts in data flow and intermittent communication failures.
o Implementing workflows.
 File storage:
o Sharing content across multiple Azure VMs.
o Migrating applications that rely on SMB protocol for data access to Azure.

Question
What type of Azure Storage would you use for storing virtual disk files for Azure virtual machines
(VMs)?
Page blobs
Block blobs
Table storage
Append blobs
File storage
Lesson 2
Create and manage storage
Implementing Azure Storage involves multiple prerequisites, such as creating and configuring a storage
account and configuring its properties. In addition, depending on the type of storage that you intend to
use, you might need to set up subcomponents of the storage accounts, such as containers, tables,
queues, and file shares. In many cases, this requires the use of specialized Azure Storage tools. In this
lesson, you will learn about these considerations.
Lesson Objectives
After you complete this lesson, you will be able to:
 Create and manage Azure Storage non-programmatically.
 Create and manage storage programmatically.
 Create a storage account and upload a blob.

 Create and manage tables programmatically.
 Create and manage blobs and tables from Microsoft Visual Studio.
Creating and managing Azure Storage non-programmatically

You can create a new storage account by using
several different methods; however, the most
straightforward option is available directly from
Azure Portal. When using the Azure Portal
interface, you will need to provide the following
information:
 Name. A unique string of between 3 and 24

characters that can contain only lowercase
letters or digits. This defines the unique URL
that other services and applications use to
access individual storage services. These URLs
include the “core.windows.net” domain suffix.
The fully qualified domain name (FQDN) depends on the custom name that you assigned and 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 https://mystorageaccount.blob.core.windows.net.
 Deployment model:
o Resource Manager
o Classic
This setting determines whether you create the storage account by using the Service Management API or
Azure Resource Manager API.
Note: Microsoft strongly recommends using the Azure Resource Manager deployment
model for any new deployments.
6-10 Cloud storage
 Account type:
o General purpose
o Blob storage
Note: For more information, refer to the “Overview of Azure Storage” topic in the
previous lesson.
 Performance:
o Standard
o Premium
Note: For more information, refer to the “Overview of Azure Storage” topic in the previous
lesson. The Premium option is available only if you select the general-purpose account type.
 Replication:
o Locally redundant storage
o Zone-redundant storage
o Geo-redundant storage
o Read-access geo-redundant storage
Note: For more information, refer to the “Storage replication options” topic in the previous
lesson. General-purpose storage accounts with Premium Storage performance are available
exclusively with the locally redundant storage option. In addition, Blob storage accounts do not
support the zone-redundant storage replication option.
 Access tier:
o Cool
o Hot
Note: For more information, refer to the “Overview of Azure Storage” topic in the previous
lesson.
 Subscription. The Azure subscription where you create the storage account.
 Resource group. The resource group where you create the storage account.
 Location. The Azure datacenter where the primary instance of your storage account will reside. This
automatically determines the location of the secondary set of copies of geo-redundant storage
accounts (both geo-redundant storage and read-access geo-redundant storage).
In general, you should choose a region that is close to users, applications, or services that are consuming
the storage account’s content. In particular, when hosting blobs for Azure VM disk files, the account must
reside in the same location in which you intend to deploy these VMs.
Graphical and command-line tools for interacting with Azure Storage

There are many tools and services that you can use to manage Azure Storage in addition to Azure Portal.
The most popular tools and services include:
 Microsoft Azure Storage Explorer. This stand-alone app allows you to manage Azure Storage from
Windows, Linux, and Mac OS X.
 Azure Web Storage Explorer. This is a web-based storage management app (implemented as an
Azure Web App).
 AzCopy.exe. This is a command-line tool designed for moving small and medium-size amounts of
data in and out of Azure. However, for very large amounts of data (that would take several days to
transfer with AzCopy) you should consider using the Microsoft Azure Import/Export service.
 Windows PowerShell. The Azure module for Windows PowerShell includes a set of Azure Storage
cmdlets, which allows you to perform a majority of Azure Storage management tasks.
 Microsoft Azure Import/Export service. The import service allows you to transfer data from your on-
premises locations to Azure Storage by using 2.5-inch SSD or 2.5- or 3.5-inch Serial Advanced
Technology Attachment (SATA) II/III internal hard drives that you ship to the target Azure datacenter.
The export service transfers data in the opposite direction. This service is intended for scenarios in
which the amount of data makes the internet-based copy overly expensive or impractical. To protect
the content of the drives, you must encrypt them with BitLocker. You manage the entire transfer
(including generation of BitLocker keys) by using Azure classic portal.
Additional Reading: For more information, refer to: “Azure Web Storage Explorer” at:
http://aka.ms/M09rms
Additional Reading: For more information, refer to: “Azure Storage Client Tools” at:
http://aka.ms/R3aaz8
Additional Reading: For more information, refer to: “Use the Microsoft Azure
Import/Export Service to Transfer Data to Blob Storage” at: http://aka.ms/Fskpq4
Creating and managing storage programmatically

After you create a storage account, you can start
creating containers and blobs by targeting
storage account blob’s endpoint. To create a
container, you can use the Azure Portal. In
addition to providing the container name, you
need to designate the container’s access type,
which determines the level of anonymous access
to its content. The default setting of Private
prevents any non-authenticated access. Choosing
the Container setting allows anonymous viewing
of the entire container (including browsing its
content for blobs). You can disable the
anonymous browsing by changing the access type setting to Blob, which effectively requires the
knowledge of the individual blobs’ URLs (including the name of the storage account, the container, and
the blob) to access them anonymously.
6-12 Cloud storage
To interact with the content of a storage account programmatically, configure the connection string to
the Azure Storage account. For example, when you create a web or worker role that requires access to a
storage account, open Solution Explorer in Visual Studio, and then, in the roles folders, open the
properties of your web role or worker role. Then, choose the Settings tab and select to add new settings.
For the new setting, you should select the Connection String type, and then type your storage account
name and access key in the Create Storage Connection String window. If the application that you are
working on is not the Azure cloud service, then you can use .NET configuration files, such as web.config
and app.config, to configure a connection string for your storage account. You store the connection
string using the <appSettings> element as follows. Replace the account name with the name of your
storage account and account key with your account access key:
<configuration>
<appSettings>
<add key="StorageConnectionString"
value="DefaultEndpointsProtocol=https;AccountName=account-name;AccountKey=account-key" />
</appSettings>
</configuration>
To access Blob storage programmatically, you should first add to your project an assembly that contains
the Azure Storage management classes. Microsoft.WindowsAzure.Storage.dll provides this functionality
and you can add it by using Package Manager from within the Package Manager console in Visual
Studio. Alternatively, you can right-click on your project in Solution Explorer in Visual Studio, and choose
Manage NuGet Packages. Then search for WindowsAzure.Storage and install it. By using this procedure,
you will receive all the necessary Azure Storage packages and dependencies.
In your code, add the using declarations referencing Azure Storage namespaces. These declarations are:
using Microsoft.WindowsAzure.Storage;
using Microsoft.WindowsAzure.Storage.Auth;
using Microsoft.WindowsAzure.Storage.Blob;
To represent your storage account, you can use the CloudStorageAccount class. When using Azure
project templates or when including references to Microsoft.WindowsAzure.CloudConfigurationManager,
you can use the CloudConfigurationManager class to retrieve your storage connection string and storage
account information from the Azure service configuration. If you do not have a reference to
Microsoft.WindowsAzure.CloudConfigurationManager, and you store your connection string data in
web.config or app.config files, you can use ConfigurationManager to retrieve the connection string.
To upload a file as a blob, by using code, you should get a container reference and use it to get a block
blob reference. When you have the reference, you can upload the data stream by using the
UploadFromStream method.
Additional Reading: For more information, refer to: “Get started with Azure Blob storage
using .NET” at: http://aka.ms/c7n9ho
Programmatic methods for interacting with Azure Storage

The most popular programmatic methods that you can use to manage Azure Storage include:
 Azure SDK for .NET. You can manage storage by using the Azure SDK for .NET. Effectively, developers
can create managed code that performs the same tasks available from Azure Portal and any of the
third-party tools.
 REST APIs for Azure. You can manage all Azure Storage by using REST APIs. Management can occur
over the internet by using HTTP or HTTPS.
 Azure Storage SDK for Java
 Azure Storage SDK for C++
 Azure SDK for PHP
 Azure SDK for Python
 Azure Storage Client Library for iOS
 Azure Storage Client Library for Xamarin
Demonstration: Creating a storage account and uploading a blob

 Create an Azure Storage account by using the Azure Portal.
 Create an Azure Storage container by using the Azure Portal.

 Upload a blob by using Azure Web Storage Explorer.
Creating and managing tables programmatically

You cannot use the Azure portal to create or
manage tables, update their content data, or
execute queries.
If you want to create, access, and manage tables
programmatically by using a Visual Studio
project, ensure that you implemented the
configuration by including and referencing
relevant storage libraries and updating
connection strings in your configuration files, as
described in the previous topic.
To create a table programmatically, use the

CloudTableClient object, which allows you to
reference tables and entities within the table. The following sample code shows how to create a
CloudTableClient object and use it to create a new table. In this case, we assume that the application we
are developing is an Azure cloud service, which uses a storage connection string configured via the
CloudConfigurationManager class, as described in the previous topic:
// Retrieve the storage account from the connection string.

CloudStorageAccount storageAccount =
CloudStorageAccount.Parse(CloudConfigurationManager.GetSetting("StorageConnectionString"))
;
// Create the table client.
CloudTableClient tableClient = storageAccount.CreateCloudTableClient();
// Create the table if it doesn't exist.
CloudTable table = tableClient.GetTableReference("people");
table.CreateIfNotExists();
Additional Reading: For more information, refer to: “Get started with Azure Table storage
using .NET” at: http://aka.ms/Gcjemy
6-14 Cloud storage
Demonstration: Creating and managing blobs and tables from

Visual Studio
In this demonstration, you will see how to manage blobs and tables by using a Visual Studio–developed
app.

Question
You need to create a Premium Storage account. Which of the following storage options can you
use in this case?
Locally redundant storage
Zone-redundant storage
Geo-redundant storage
Read-access geo-redundant storage
Blob storage account type

Lab: Configure Azure Storage

Scenario
A. Datum has an archive of media files stored on your on-premises file servers. You want to perform a
test transfer of these files to Azure Blob storage.
Objectives
After you complete this lab, you will be able to:
 Create an Azure Storage account and a blob container.
 Upload a blob to the storage account container.
Lab Setup

User name: Admin
Password: Pa55w.rd
o User name: Admin
Exercise 1: Creating an Azure Storage account

Scenario
Before you start managing your data in Azure, you should first create a storage account, examine the
account’s properties, and copy its access key to a text file.
6-16 Cloud storage
Exercise 2: Creating and managing blobs

Scenario
Now that you have created your storage account, you need to create a container and upload data to the
container.
The main task for this exercise is as follows:
1. Prepare for the next module.
 Task 1: Prepare for the next module

 When you have finished the lab, do not revert the virtual machines. Please keep all of the VMs
running. The VMs in their current state are required for the next module.
Question: Can you convert a Standard storage account to a Premium Storage account?
Question: Is it possible to upload a file to an Azure Storage blob by using the Azure portal?

Best Practice
By following the best practices for using Azure Storage, you can minimize its cost. The four factors that
will influence your costs are:
 Amount of storage used (with Standard storage) or provisioned (with Premium Storage). Consider
using Standard storage disks for volumes hosting the operating system and carefully estimate the
optimum size of Premium Storage disks.
 Replication options. Geo-redundant storage accounts are more expensive than locally redundant
storage. One way to reduce costs is to create multiple storage accounts with replication settings
configured individually according to the resiliency requirements of their content.
 Number of storage transactions. Transactions are defined as operations (such as create, read, or
write) across all Azure Storage types including blobs, tables, queues, and files. One way to minimize
these charges is to ensure that VMs rely on temporary disks for hosting non-persistent content (such
as their paging files). This cost is not applicable to Premium Storage accounts.
 Egress data from the Azure region hosting the storage account. To minimize these charges, you
should consider grouping interdependent services together in the same region.
Note: For more information, refer to: “Azure Blobs Storage Pricing” at: http://aka.ms/Lfqijq
Review Question
Question: If you want to store installation image files that will be accessed via the SMB
protocol by multiple Azure VMs, which type of storage should you choose?
Tools
The following is a list of the tools that this module references:
 Azure Portal
 Microsoft Visual Studio
 Microsoft Azure Storage Explorer
 Azure Web Storage Explorer
 AzCopy.exe
 Microsoft Azure Import/Export service

7-1
Module 7
Microsoft Azure databases
Contents:
Module Overview 7-1
Lesson 1: Understanding options for relational database deployments 7-2
Lesson 2: Creating and connecting to Azure SQL databases 7-6

Lab: Creating a SQL Database in Azure 7-11
Module Overview
Microsoft Azure offers a range of services that you can use to manage data. In particular, Azure provides
relational database-management services. You can use these services to implement a relational data
store for applications, without having to manage a database management system (DBMS) or the
operating system that supports it.
In this module, you will learn about the available Azure options for storing relational data. You also will
learn how to use Microsoft Azure SQL Database, which enables you to create, configure, and manage
SQL databases.
Objectives
 Describe options for relational database deployment in Azure.

 Use Azure to create, connect to, and manage content of SQL databases.
7-2 Microsoft Azure Databases
Lesson 1
Understanding options for relational database
deployments
Azure provides two basic methods of deploying relational database services: Platform as a service (PaaS)
and infrastructure as a service (IaaS). The method you select will depend primarily on the requirements of
the applications that consume database content. However, you should also consider factors such as
manageability, ease of provisioning, cost, and compatibility. Compatibility is especially relevant in
migration scenarios. This lesson introduces the relational database services that are available in Azure
and describes how you can choose the best solution for your specific application and business needs.
Lesson Objectives
 Describe relational database services in Azure.
 Describe the key differences between a SQL database in Azure and a Microsoft SQL Server.
Review relational database deployment options

Most business applications rely on a relational
database to store their data, which typically
includes a collection of two-dimensional tables that
represent real-life entities and the relationships
between them. Table rows correspond to individual
instances of these entities, whereas table columns
describe their identifying properties. However, by
combining multiple interrelated tables, you can
express complex business scenarios in a simple
manner, and you can analyze their characteristics to
extract meaningful information.
When you deploy relational databases to Azure,

you can choose from a range of deployment options. All of these options pertain to distinct service and
product types. Azure provides two basic types of relational database services that each support different
product types:
 PaaS. This service allows you to focus on database-specific tasks, because you do not need to
manage the underlying database server and operating system platforms. The two primary options
are SQL Database and MySQL Database. Microsoft SQL Server technologies provide the basis for
SQL Database, while the basis for MySQL Database is the ClearDB MySQL Database cloud service,
which is available in the Azure Marketplace.
 IaaS. You can deploy Azure IaaS virtual machines that host an instance of a relational database
management system (RDBMS). This can include instances of SQL Server, MySQL, or any database
server, such as DB2, Oracle, SAP Adaptive Server Enterprise (ASE), or SAP HANA, that is supported on
operating system platforms that you can install on Azure IaaS virtual machines.
Compare SQL database with SQL Server in a virtual machine

When you use Azure to implement a Microsoft SQL
Server-based database, you can deploy it onto a
Microsoft SQL Server instance that is running in an
Azure VM or as a SQL database in Azure. The
following characteristics of these two solutions can
help you determine the best solution for your
organization. The characteristics to consider
include:
 Manageability, maintenance, and cost. Azure

SQL Database constitutes a PaaS solution that
removes much of the overhead associated with
deploying and maintaining relational database
systems. It is appealing because the operational costs are less than other options, and it provides a
simplified management approach. On the other hand, when you provision and manage SQL Server
instances that are running on Azure IaaS virtual machines, you can manage and control them in the
same manner as their on-premises counterparts, and their pricing includes the cost of the dedicated
virtual machine.
Note: You should note that you can reduce your management overhead significantly for
implementing SQL Server instances that are running on Azure IaaS virtual machines by taking
advantage of SQL Server Virtual Machine Automated Patching and SQL Server Virtual Machine
Automated Backup. These technologies rely on the SQL Server IaaS Agent extension of the VM
Agent (to automatically deploy Microsoft updates to, and back up SQL Server databases of,
Azure IaaS virtual machines. Additionally, SQL Server Virtual Machine Automated Backup also
uses SQL Server Managed Backup to Microsoft Azure. This functionality is available for SQL
Server 2012, SQL Server 2014, and SQL Server 2016 instances.
 Feature parity with on-premises deployments of SQL Server. SQL Server instances that are running
on Azure IaaS virtual machines provide optimal compatibility with existing database applications.
However, you might have to resolve incompatibility issues that result from migrating from on-
premises SQL Server databases to Azure SQL databases.
Additional Reading: For a comprehensive list of features that SQL databases support,
refer to: http://aka.ms/N7d08a
Additional Reading: For a comprehensive list of differences of Transact-SQL related

functionality between SQL Server and Azure SQL Database, refer to: “Azure SQL Database
Transact-SQL differences” at: http://aka.ms/Ps3svp
Additional Reading: For information about identifying and resolving database-

compatibility issues by using SQL Server Database Migration Wizard, refer to:
http://aka.ms/Qmu1ip
Please note that the SQL Server 2016 Upgrade Advisor includes most of the SQL Database
Migration Wizard features and additionally, it extends that functionality by adding support for
migration of Full-Text search functionality.
 SQL Server components. SQL Server instance-level components require a SQL Server instance
running within an Azure IaaS virtual machine. These components include SQL Server Agent, SQL
Server Analysis Services, SQL Server Integration Services, SQL Server Reporting Services, or Master
Data Services. . However, you might be able to provide equivalent functionality by taking advantage
of other Azure services, such as Azure SQL Data Warehouse, Azure Data Lake, or Azure Data Factory.
Note: In absence of SQL Server Agent, you can use Elastic Database jobs to implement
scheduled, automated maintenance tasks of Azure SQL Database. When you do this, you can run
arbitrary Transact-SQL scripts or apply data-tier applications across a collection of Azure SQL
databases.
 Ability to make a relational database interact directly with other Azure services within the same
Azure virtual network. You can locate SQL Server instances that are running within an Azure IaaS
virtual machine on the same Azure virtual network as the IaaS virtual machine or PaaS cloud services.
However, with SQL Database, network traffic always flows via its public IP address. Therefore,
depending on your architectural design, this might help provide an additional level of integration or
isolation in relation to other Azure services and public networks.
 High availability and scalability. Azure supports high availability and scalability features, including
AlwaysOn Availability Groups, database mirroring, or SQL Server replication, only if you use a SQL
Server instance that is running within an Azure IaaS virtual machine. However, you can use Azure SQL
Database to achieve an equivalent resiliency level with much less management overhead, and you do
not need to rely on these features. However, you can use the built-in capabilities of Azure SQL
Database service, such as geo-replication, point-in-time restore, or geo-restore. You also can scale
both horizontally and vertically. You can scale horizontally by partitioning data with Elastic Database
tools, and you can scale vertically by changing service tiers and their performance levels. Azure SQL
Database is available in three service tiers: Basic, Standard, and Premium, and performance levels are
expressed in database throughput units (DTUs). A DTU is a number that represents the overall power
of the database engine resources, including processor, memory, and input/output.
 Authentication. With Azure SQL Database, your options include SQL Server and Azure Active
Directory authentication. When you host a SQL Server in an Azure virtual machine, you have the full
support of authentication methods that are available in on-premises deployments, including
Windows authentication.
SQL database resiliency and scalability

Every SQL Database consists of three
synchronously replicated copies residing in the
same Azure region. All SQL databases are backed
up automatically, with full backups taking place
weekly, differential backups happening daily, and
transaction log backups performed every five to
ten minutes, depending on the volume of database
changes and the database performance. The
corresponding Point In Time Restore window,
during which you can restore backups, varies from
seven days to 35 days, depending on the pricing
tier. You can restore in another Azure region if the
primary one becomes unavailable. This functionality is known as Geo-Restore.
Although Point In Time Restore and Geo-Restore allow you to recover data in the event of a database,
server, or datacenter failure, the time it takes to recover the database might result in some downtime of
business-critical applications. To reduce the time taken to recover applications that rely on a SQL
database, you can implement Geo-Replication. This involves creating up to four secondary, read-only,
replica databases residing in other, arbitrarily chosen Azure regions. Each secondary database is
automatically replicated asynchronously from the primary region. In the event of a failure, you can fail
over to the secondary database. Following the failover, you should modify the connection strings of your
applications to point them to the secondary replica. This extra step typically takes much less time than
restoring a large database from a backup.
Azure SQL Database supports vertical scaling. To implement it, you change the database pricing tier or
performance level. The change affects the database throughput units that the database can support.
Horizontal scaling requires more effort because it involves splitting data into separate sets and
integrating them through federations, or sharding. However, Elastic Database tools available with Azure
SQL Database considerably simplify the process of implementing these processes.
An innovative approach to scaling of Azure SQL Database involves automatic distribution of pre-
allocated resources determined by the pricing tier among multiple databases that are hosted on the
same logical server by combining them into elastic database pools. Each server can contain a number of
pools, but each pool can be associated only with a single server. After you create a pool and add it to a
server, you must decide how many resources you want to make available to it. Similar to the traditional
approach, you do this by assigning a pricing tier. You can pool and assign resources on an as-needed
basis. As part of the pool configuration, you can also set the minimum and maximum performance levels
and database size, to ensure that individual databases do not monopolize all the resources allocated to
the pool.
If you have groups of databases with varying usage patterns, elastic database pools typically yield
significant cost savings and performance improvements. The Azure platform tracks and analyzes these
patterns to identify the most optimal arrangements of databases across elastic pools. You can use results
of this analysis when creating and configuring elastic pools in the Azure portal.

Question
Which of the following features increase resiliency of Azure SQL database?
Point In Time Restore
Sharding
Elastic Database pools
Geo-Replication
Geo-Restore
Lesson 2
Creating and connecting to Azure SQL databases
Azure SQL Database is a cloud-based SQL service that provides subscribers with a highly scalable
platform for hosting their databases. When you use Azure SQL Database, organizations can avoid the
cost and complexity of managing SQL Server installations and quickly set up and start using database
applications.
In this lesson, you will learn how to provision and connect to an Azure SQL database.
Lesson Objectives
 Describe how to create and import Azure SQL databases.
 Create a new Azure SQL database by using the Azure portal.
 Configure resiliency of Azure SQL databases.

 Connect to a SQL database in Azure.
Create and import SQL databases

To provision a new SQL database in Azure, you
must understand the foundations of its
architectural model. Azure SQL Database depends
on the existence of an Azure SQL server, which
serves some of the functions provided by a SQL
Server instance in on-premises environments.
Azure SQL servers are logical systems that host SQL
databases. Each SQL database server has a unique
domain name system (DNS) name, local
administrator account, and firewall rules restricting
access to its databases. Such servers host individual
instances of Azure SQL Database in addition to the
master database that stores server configuration data. Databases located in this logical server likely
reside on different physical servers, but all are accessible through the same endpoint address.
The most straightforward way to provision a SQL database in Azure relies on the graphical interface of
the Azure portal. The process requires that you designate a logical server (either an existing or a new
one) on which to host the database. Alternatively, you can first create a new logical server and add a new
database to it afterward.
While it is possible to create Azure SQL databases and configure their database-level settings when you
use standard Azure management tools (including the Azure portal and Windows PowerShell), managing
their content requires a different approach. This approach involves the use of traditional database
administrative and development tools, such as SQL Server Management Studio, Microsoft Visual Studio,
or the sqlcmd command-line tool.
Creating a SQL database

When you create a database from the preview Azure portal, you must include the following information:
 A name for the database. The name must be unique on the server (but does not need to be unique
globally).
 The SQL Database pricing tier, which directly affects the cost of the database and also determines
the following elements:
o Performance level that represents the database capacity to handle transactional workload.
o Maximum size to which the database can grow.

o Supported resiliency features, such as the retention period for automatic backups.
o Support for auditing.
 The collation to which you want the database to apply. The collation defines the rules that determine
how to sort and compare data.
 The server on which to create the database. You can select an existing server that you have
previously created in the same subscription or create a new server. The server name must be unique
globally.
 The resource group in which to create the database and its server. If you select an existing server, the
database is automatically added to the existing resource group to which the server belongs. The
name of the resource group must be unique within the current subscription.
Creating a SQL Server instance

You can create a server instance on its own or as part of the process of creating a database. In scenarios
where you provision new databases for applications, you typically create the server as part of the process
of creating the first database. However, in some cases, you might want to create the server without any
user databases and then add databases to it later; for example, when you migrate the databases from an
on-premises SQL Server instance. Each server must have a name that is unique globally. The fully
qualified domain name (FQDN) of the server is in the form <server_name>.database.windows.net; for
example, abcde12345.database.windows.net.
When you create a server, you must specify the following information:
 A globally unique server name (unique in the database.windows.net).
 A sign-in name and password for the administrative account that you will use to manage the server.
 The Azure region where the server should be located.
 Whether to allow other Azure services to connect to the server. Enabling access from Azure services
creates a firewall rule that permits access from the IP address 0.0.0.0.
Importing data into a SQL database

A common method for populating a newly created SQL database is to import its content from another
database, such as one that an on-premises SQL Server instance is hosting. You might use this method
when migrating an on-premises application to the cloud. It might also be necessary because developers
created a database by using a full-fledged development instance of SQL Server in preparation for
deploying it to a production environment in SQL Database.
The import process must take into account two types of content. The first content type is the database
schema, which contains definitions of all database objects. The second content type is the actual data
stored in each of the database objects.
You can use the following three techniques to migrate both types of content from a SQL Server–hosted
database to Azure SQL Database:
 Run the SQL Server Management Studio Migration Wizard. This method is suitable for small to
medium databases with a reliable connectivity between the source and target databases.
 Export a data-tier application (DAC) from SQL Server in the form of a .bacpac file and import it into
Azure SQL Database. You have the option of storing both the .bacpac file, which contains both the
schema and the existing data. This method is recommended in scenarios where connection between
the source and target databases is slow or unreliable.
 Use the .bacpac file to migrate the schema only and use the SQL Server bcp utility to transfer data.
This approach is best for handling transfer of larger databases.
Using Copy to create a SQL database

You can easily copy your existing database within a SQL server in Azure or between two SQL servers in
Azure that belong to the same subscription. You can do so from the Azure portal (by clicking Copy in the
blade of the database you are copying) or by running the corresponding T-SQL Statement. This method
is useful for performing an impromptu backup of the source database before making changes to it or for
creating its replica for testing purposes.
You can create a copy of an existing SQL Database by running the following T-SQL statement. Note that
you must execute this command while connected to the master database of the Azure SQL server that
will host the copy.
CREATE DATABASE T-SQL statement

CREATE DATABASE destination_database_name
AS COPY OF [source_server_name.]source_database_name
Demonstration: Create a new SQL database by using the Azure Portal

 Create a SQL database in the Azure portal.
 Identify the SQL database and the SQL database server properties in the Azure portal.
Demonstration: Configure geo-replication settings of an Azure SQL

database by using the Azure portal
 Configure geo-replication.
Connect to an Azure SQL database

The primary purpose of the SQL Database service is
to provide data storage for applications that deliver
specific business functionality. However, SQL
Database must also facilitate easy access to
developers who create these applications and to
database administrators and development
operations staff who assist developers. This topic
reviews different ways for providing access to data
storage.
While you typically handle the creation and

management of SQL Databases on the database
level by using the Azure portal and the preview
Azure portal or Windows PowerShell, the ability to perform create, read, update, and delete operations
on database content requires a different approach. The approach to connecting to SQL databases in
Azure is similar to the approach for working with on-premises SQL Server-hosted databases, allowing the
use of the following tools:
 SQL Server Management Studio. You can use SQL Server Management Studio to connect to an
Azure SQL Database server and administer it like the SQL Server instances. In hybrid IT environments,
it is convenient to use the same tool to manage on-premises or Azure IaaS-based SQL Server
instances and SQL Database servers.
 sqlcmd. You can use the sqlcmd command-line tool to connect to Azure SQL Database servers and
execute Transact-SQL commands.
 Visual Studio. Developers can use Visual Studio to create SQL databases and to manage and query
their content.
Note: You can also query and modify the content of an Azure SQL database directly from
the Azure portal by using SQL Database Query Editor. The editor is accessible via the Tools icon
in the toolbar of the SQL database blade. This feature is in preview at the time of authoring this
course.
It is important to remember that you must configure SQL Server firewall settings in Azure to explicitly
allow incoming connections originating from a non-Azure location. If you intend to use the tools listed
above from an on-premises environment, first modify the Azure SQL Server firewall settings by allowing
connectivity from the public IP address of the perimeter network device through which you connect to
the Internet. You can identify this IP address easily in the Azure portal and simplify creation of the
corresponding rule if you use the web-based SQL Database management interface. On the other hand,
connections originating from any Azure subscription are allowed by default. While you can change this
setting, consider the impact on connections from your Azure-hosted applications that rely on SQL
Database for data storage before doing so.
In order to connect to SQL Database programmatically, you must configure your applications with
connection strings, which you can readily extract from the Azure portal, as shown in the previous
demonstration in this module. Keep in mind that SQL databases are not capable of using Integrated
Windows Authentication. Instead, you will need to rely on SQL Server or Azure Active Directory
authentication.
Demonstration: Connect to an Azure SQL Database by using SQL Server

Management Studio and an Azure web app
 Connect to a SQL database by using SQL Server Management Studio.
 Connect to a SQL database from an Azure web app.
Question: How will your organization use Azure SQL Database?

Lab: Creating a SQL Database in Azure

Scenario
To accommodate a steadily increasing volume of Internet-based customers, A. Datum has decided to
store its marketing data in a dedicated database hosted in Microsoft Azure. You are considering using
Azure SQL Database for this purpose and have decided to test its capabilities.
Objectives
After completing this lab, students will be able to:
 Create an Azure SQL database.
 Create a table in an Azure SQL database.
 Add data to a table in an Azure SQL database.

 Query the content of a table in an Azure SQL database.
Lab Setup
User name: Admin
Password: Pa55w.rd

o User name: Admin
5. You also need to start MSL-TMG1 for Internet access.
Question: In the lab, you connected to an Azure SQL database by using SQL Server
Management Studio. What configuration change must you make first in the Azure portal before
successfully establishing the connection?
Question: What authentication method do you have to use when connecting to Azure SQL
Database?

Review Question
Question: What should you consider when choosing between on-premises SQL Server, SQL
Server on an Azure virtual machine, and Azure SQL Database?
Tools
Most common tools for managing content of Azure SQL databases match those that you would use to
manage on-premises SQL Server databases and include:
 SQL Server Management Studio. You can use SQL Server Management Studio to connect to an
Azure SQL Database server and administer it in a manner similar to the management of SQL Server
instances.
 sqlcmd. You can use the sqlcmd command-line utility to connect to Azure SQL Database servers and
execute Transact-SQL commands.
 Visual Studio. Developers can use Visual Studio to create SQL databases and to manage and query
their content.
8-1
Module 8
Creating and managing Azure AD
Contents:
Module Overview 8-1
Lesson 1: Overview of Azure AD 8-2
Lesson 2: Manage Azure AD authentication 8-12

Lab: Create and manage Azure Active Directory tenants 8-15
Module Overview
Microsoft Azure Active Directory (Azure AD) is a cloud-based identity and access-management solution
that provides authentication and authorization when users require access to cloud-based resources.
However, you also can leverage its functionality to protect on-premises applications. Additionally, you
can streamline and enhance secure access to sensitive services and data by utilizing Azure AD’s single
sign-on (SSO), federation, and Azure Multi-Factor Authentication capabilities.
In this module, you will learn how to create users, domains, and directories in Azure AD, integrate
applications with Azure AD, and use Multi-Factor Authentication.
Objectives
 Create and manage Azure AD tenants, domains, and users.

 Manage Azure AD authentication.
8-2 Creating and managing Azure AD
Lesson 1
Overview of Azure AD
Azure AD is a cloud-based identity and access-management solution, and a directory-services solution
that you can use 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 compares these two technologies.
Lesson Objectives
 Describe the main characteristics of AD DS.
 Explain how you can extend the scope of AD DS.
 Describe the main characteristics of Azure AD.

 Create Azure AD tenants, domains, and users.
 Assign Azure AD users to applications.
What is AD DS?
AD DS forms the foundation of enterprise networks
that run Windows operating systems. The core
component of AD DS is its database, which
provides storage for all AD DS objects, such as
user accounts, computer accounts, or group
accounts. The database schema defines object
types, typically referred to as classes, and their
individual properties, also known as attributes. The
database organizes objects in a customizable,
logical hierarchy that consists of containers and
organizational units (OUs). The database offers
resiliency by supporting multiple replicas that
servers, or domain controllers, host. The database constitutes the authoritative source of identity data for
domain objects, which means that AD DS functions primarily as an identity provider.
Identity data
Identity, in the context of this course, is data that uniquely identifies an entity, such as a user or a
computer. Identity describes each entity’s characteristics, and it provides information about the entity’s
relationships to other entities. AD DS domain controllers use authentication to verify authenticity of a
domain’s identifying data. Authentication typically requires that a user or computer that is attempting to
authenticate provide credentials to the authenticating domain controller. The result of this process is that
the authenticating domain controller grants that user or computer a token that represents its status and
privileges to other domain members. Through this authorization process, the user or computer
subsequently uses the token to obtain 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 its corresponding domain controllers. You establish this trust by
joining the domain, which adds an account that represents your computer to the AD DS database.
Directory service
AD DS, as the name indicates, also functions as a directory service, and allows you to query an AD DS
database’s contents. AD DS–aware applications, such as Microsoft Exchange, use this functionality
extensively, because these applications rely on AD DS to store their configuration and operational
parameters. 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.
AD DS configuration
AD DS advertises its services by using Domain Name System (DNS). Effectively, each AD DS domain has a
unique DNS domain name. While it is possible to use multiple, distinct DNS namespaces within the same
domain, doing so is uncommon.
Each AD DS domain exists within an AD DS forest, and a forest can contain multiple domains. All
domains in the same forest share the same schema, and implicitly trust each other. Therefore, this
extends the scope of authentication, authorization, and directory-services lookups to all forest objects. If
you want to provide the same functionality across multiple forests, you need to create trust relationships
between them.
AD DS has a multipurpose nature, and its intended operational model is as a fully managed infrastructure
component. Therefore, it offers a high degree of versatility and customizability. You can delegate its
permissions down to a single object’s individual attribute. Additionally, because the database replicates
and distributes, it can host millions of objects by scaling up, and it can support multinational enterprises
with datacenters on multiple continents by scaling out. You can extend its schema to accommodate
custom object types, although it is important to note that schema extensions are not fully reversible.
Implementing AD DS in Azure
AD DS offers significant business and technological
benefits. However, it mainly is for on-premises,
independently managed deployments, and most of
its characteristics reflect this underlying premise. Its
authentication and authorization mechanisms 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 version 5 for authentication; and Server
Message Block (SMB) for downloading Group
Policy data. However, none of these protocols are suitable for Internet environments.
Multi-tenancy is very difficult to implement within a single domain. You can provide more autonomy by
deploying additional domains within the same forests, or by deploying multiple forests with trust
relationships among them. However, these methods are complex to configure and manage. AD DS
enables you to implement the desired mix of efficiency, control, security, and flexibility within corporate
networks, but it does not work well with today’s open, Internet-facing world that is dominated by cloud
services and mobile devices.
Extending AD DS authentication
You can address this shortcoming by extending the capabilities of AD DS. You do this by using an
intermediary system that handles translation of AD DS on-premises constructs and protocols, such as
tokens and Kerberos, into their Internet-ready equivalents. The AD FS server role and Web Application
Proxy server feature of Windows Server provides this functionality. As a result, users, devices, and
applications can take advantage of the AD DS authentication and authorization features without having
to be a part of the same domain or a trusted domain.
Federation support
Federation support is the primary feature that AD FS and Web Application Proxy facilitate. A federation
resembles a traditional trust relationship, but relies on claims (contained within tokens) to represent
authenticated users or devices, and it relies on certificates to establish trusts and to facilitate secure
communication with an identity provider. Additionally, it uses web-friendly protocols such as HTTPS, Web
Services Trust (WS-Trust), Web Services Federation (WS-Federation), or Open Authorization (OAuth) to
handle transport and processing of authentication and authorization data. This means that AD DS, in
combination with AD FS and Web Application Proxy, can function as a claims provider, authenticating
requests from web-based services and applications that cannot access AD DS domain controllers directly.
Azure IaaS
You also can extend AD DS into the cloud by deploying AD DS domain controllers into Azure virtual
machines. You might use this type of deployment to build a disaster-recovery solution for an existing on-
premises AD DS environment, to implement a test environment, or to provide local authentication and
authorization to Azure-hosted, AD DS-dependent applications and services that reside within the same
Azure virtual network.
Azure AD DS
If you need to deploy AD DS-dependent applications and services into Azure, but you want to avoid the
overhead associated with deploying and managing Active Directory domain controllers hosted on IaaS
Azure virtual machines, you should consider implementing Azure Active Directory Domain Services
(Azure AD DS) instead.
Azure AD DS provides a Microsoft-managed AD DS service, which you can enable when necessary. The
service consists of two Active Directory domain controllers in a new, single domain forest. These two
Active Directory domain controllers deploy automatically to an Azure virtual network that you designate,
and you can enable this functionality by using the Azure classic portal within your Azure AD tenant. This
establishes a one-to-one relationship between the two directories, and triggers automatic
synchronization. The result is that the Azure AD DS domain contains the same users and groups as its
Azure AD counterpart. Therefore, when you deploy Azure IaaS virtual machines into the Azure virtual
network that hosts the Azure AD DS domain controllers, and you then join them to the corresponding
Azure AD DS domain, Azure AD users can use their existing credentials to sign in to these virtual
machines.
If you have an on-premises Active Directory domain, you also can synchronize it with an Azure AD
tenant. If you configure synchronization and enable Azure AD DS in that Azure AD tenant, your on-
premises users can sign in to the Azure AD DS domain by using their existing credentials. However,
please note that your on-premises AD DS domain is separate from the Azure AD DS domain. The two
domains have different domain names and a different set of domain controllers. However, the ability of
users to sign in with the same credentials in the on-premises AD DS and the corresponding Azure AD DS
is a direct result of the synchronization across the three directories, and the Azure AD tenant acts as the
intermediary.
Overview of Azure AD
The previous topics in this module described the
role of AD DS as an identity provider, a directory
service, and an access management solution.
They also showed how you can extend the scope
of AD DS into the cloud to accommodate
authentication and authorization requirements
of Internet and Azure-based applications and
services. You have the additional option of
accommodating these requirements by relying on
features supported natively by cloud-based identity
providers. Azure AD is an example of such a
provider.
Presenting the role of Azure AD as a cloud-based counterpart of AD DS would be an oversimplification;

while they share some common characteristics, there are several significant differences.
Azure AD operates as a Microsoft-managed service that is part of the platform as a service (PaaS)
offering. It is not a part of core infrastructure that customers own and manage, nor is it an IaaS offering.
While this implies that you have less control over its implementation, it also means that you do not have
to dedicate resources to its deployment or maintenance. You also have access to a set of features not
natively available in AD DS, such as support for Multi-Factor Authentication.
Azure AD tiers
Azure AD constitutes a separate Azure service. Its most elementary form, which any new Azure
subscription includes automatically, does not incur any extra cost and is referred to as Free tier.
Note: By default, when you create a new Azure subscription by using a Microsoft account,
the subscription automatically includes a new Azure AD tenant named Default Directory.
Some of the more advanced identity management features require paid versions of Azure AD, offered in
the form of Basic and Premium tiers. Some of these features are also automatically included in Azure AD
instances generated as part of Office 365 subscriptions. In addition to differences in functionality, the
Free tier is subject to the 500,000-object limit and does not carry out any service level agreement (SLA)
entitlements. Both Basic and Premium tiers do not impose restrictions on the total number of directory
objects and offer 99.9 percent uptime SLA. The Premium tier consist of two subtiers, P1 and P2. P2 offers
identity protection features to help identify and address attempts to compromise privileged Azure AD
accounts.
Azure AD tenants
Unlike AD DS, Azure AD is multi-tenant by design and is implemented specifically to ensure isolation
between its individual directory instances. It is the world’s largest multi-tenant directory, hosting well
over a million directory services instances, with billions of authentication requests per week. 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 the technical standpoint, the term tenant represents an individual
Azure AD instance. As an Azure customer, you can create multiple Azure AD tenants. Having multiple
Azure AD tenants might be handy if you want to test Azure AD functionality in one without affecting the
others.
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 Role-Based Access Control [RBAC]) to users, groups, and applications 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 applications to
manage resources across multiple Azure subscriptions.
Each Azure AD tenant is assigned the default DNS domain name, consisting of a unique prefix. The prefix,
derived from the name of the Microsoft account you use to create an Azure subscription or provided
explicitly when creating an Azure AD tenant, is followed by the onmicrosoft.com suffix. Adding at least
one custom domain name to the same Azure AD tenant is possible and common. This name utilizes the
DNS domain namespace that the corresponding company or organization owns. The Azure AD tenant
serves as the security boundary and a container of Azure AD objects such as users, groups, and
applications. A single Azure AD tenant can support multiple Azure subscriptions.
Azure AD schema
The Azure AD schema contains fewer object types than that of AD DS. Most notably, it does not include a
definition of the computer class, although it does include the device class. (The process of joining devices
to Azure AD differs considerably from the process of joining computers to AD DS.) The Azure AD schema
is also easily extensible, and its extensions are fully reversible.
The lack of support for the traditional computer domain membership means that you cannot use Azure
AD to manage computers or user settings by using Group Policy Objects (GPOs). Instead, its primary
strength lies in providing directory services; storing and publishing user, device, and application data;
and handling the authentication and authorization of the users, devices, and applications. The
effectiveness and efficiency of these features are apparent based on existing deployments of cloud
services such as Office 365, which rely on Azure AD as their identity provider and support millions of
users.
Note: To manage Azure AD joined devices, you can use mobile device management
solutions, such as Microsoft Intune.
Azure AD does not include the organizational unit class, which means that you cannot arrange its objects
into a hierarchy of custom containers, frequently used in on-premises AD DS deployments. However, this
is not a significant shortcoming, because organizational units in AD DS are used primarily for Group
Policy scoping and delegation. You can accomplish equivalent arrangements by organizing objects based
on their group membership.
Applications are represented in Azure AD by objects of the Application class and servicePrincipal class,
with the former containing an application definition and the latter constituting its instance in the current
Azure AD tenant. Separating these two sets of characteristics allows you to define an application in one
tenant and use it across multiple tenants by creating a service principal object for this application in each
tenant, which takes place when you register the corresponding application in that Azure AD tenant.
Azure AD delegation model

Because of its operational model as software as a service (SaaS) and its lack of both management
capabilities via Group Policy settings and support for computer objects, the delegation model
within Azure AD is considerably simpler than the same model in AD DS. There are several built-in
roles in all three tiers, including Global Administrator, Billing Administrator, Service Administrator,
User Administrator, and Password Administrator. Each role provides different levels of directory-wide
permissions to its objects. By default, the Service Administrator of the subscription hosting the Azure AD
instance is its Global Administrator, with full permissions to all objects in their directory instance.
The delegation model provides the ability to grant permissions to applications registered in an
Azure AD tenant to its users and groups, and management of the delegate group. The specifics of
these capabilities depend on the AD tier. For example, in Azure AD Free, you can assign applications to
individual users. With the Azure AD Basic tier, you can also create such assignments based on the group
membership. The Premium tier further extends this functionality by offering delegated and self-service
group management, thereby allowing users to create and manage their own groups, and request
membership in the groups created by others.
Note: Azure AD users can access Azure AD applications by using the web-based portal
referred to as the Access Panel at: http://aka.ms/Fim3qw. This portal automatically presents to
the users all applications for which they have permissions. Another benefit of using this
approach is the support for SSO. When starting individual applications from its interface,
authentication happens automatically once users sign in to the portal.
Azure delegation Model - RBAC

The delegation model described above deals with permissions to Azure AD tenant objects and is
available via the graphical interface in the Azure classic portal. You also can manage permissions to
resources within the Azure subscription associated with the Azure AD tenant by implementing RBAC. This
mechanism relies on a number of built-in and custom-defined roles (the latter at this point requires the
use of Azure PowerShell). Each of these roles represents a specific set of actions on Azure resources such
as Azure Web apps, SQL databases, Azure virtual machines, or even their individual network adapters.
You can grant the intended access by associating an Azure AD object such as a user, group, or service
principal with a role and assigning it on the resource, resource group, or subscription level.
Authenticating access to Azure web applications by using Azure AD

The process of implementing Azure AD support for custom applications is rather complex and beyond
the scope of this course. However, the Azure portal and Microsoft Visual Studio make the process of
configuring such support more straightforward.
In particular, you can enable Azure AD authentication for Azure Web apps directly from the
Authentication/Authorization blade in the Azure portal. By designating the Azure AD tenant,
you can ensure that only users with accounts in that directory can access the website. It is possible
to apply different authentication settings to individual deployment slots.
Additional Reading: For more information regarding configuring Web App Azure AD
authentication, refer to: “How to configure your App Service application to use Azure Active
Directory login” at: http://aka.ms/L27lid
In the case of Visual Studio, when developing Azure web app projects, you can choose to configure
authentication based on organizational accounts, automatically register the application with Azure AD,
and assign its access level to directory content. When using older versions of Visual Studio, you must
register the application manually. You can do this by adding its unique identifier, referred to as App ID
Uniform Resource Identifier (URI), to the target Azure AD tenant in the Azure classic portal.
Azure AD federations
In Azure AD, the role of federations is equivalent to trust relationships between AD DS domains and
forests. This allows for the integration of its directories with cloud services and for interaction with
directory instances of other identity providers. For example, such federation trust exists between
Azure AD and the Microsoft identity provider that hosts Microsoft accounts, formerly known as Live ID
accounts. This means that an Azure AD tenant user account can directly reference an existing Microsoft
account using the existing account to sign in to that Azure AD tenant. You can also use AD FS and Web
Application Proxy to establish such federations with on-premises AD DS deployments.
The use of federations eliminates the dependency on AD DS protocols such as Kerberos, which are
intended for on-premises, LAN-based communication. Instead, the federation traffic travels over cloud-
friendly HTTPS protocol, carrying WS-Trust, WS-Federation, SAML, or OAuth communication. Instead of
using LDAP-based lookups, Azure AD interaction relies on AD Graph application programming interface
(API).
Azure AD identity support

Built-in capabilities as an identity provider and its support for federations allows Azure AD to offer
flexibility in designing an identity solution for your organizational or business needs. This flexibility gives
you four high-level design choices:
 Implementing authentication exclusively in Azure AD. This means that identity data, including user
credentials, resides only in the cloud. You can define the identities directly in Azure AD or source
them from existing Microsoft accounts, based on the federation with the Microsoft identity provider.
You might prefer this choice if you do not have an existing or significant on-premises AD DS
deployment.
 Maintaining an on-premises authoritative source of the identity data in AD DS but synchronizing it
to Azure AD at regular intervals. This means Azure AD can authenticate and authorize users, but you
retain control over their state in the on-premises AD DS. This approach simplifies application support
of AD DS users who are not operating on-premises. It is also suitable in scenarios where a large
number of AD DS users rely on Microsoft cloud services, such as Office 365, to access their
applications.
 Taking advantage of the AD FS capabilities (which this topic covered earlier) to authenticate
users accessing cloud resources. This approach involves forming a federation between your on-
premises AD DS and Azure AD. Authentication requests submitted to Microsoft cloud resources
are redirected from the cloud to your on-premises AD DS via the AD FS server. This allows you to
provide authentication and authorization to cloud-based services by using your on-premises AD DS.
This approach is similar to the second one, but its advantage is support for SSO. Its drawback is the
need for additional servers that are hosting federation components.
 Relying on pass-through authentication to validate credentials of users attempting to access
Microsoft cloud resources. Similar to federation, pass-through authentication relies on AD DS to
perform the validation. However, it does not require a dedicated server infrastructure. Instead, it
uses a lightweight agent running on one or more domain-joined Windows Server 2016 or Windows
Server 2012 R2 computers. These computers must have direct connectivity to an Active Directory
domain controller and an outbound connectivity to the Internet. The agent accepts password
validation requests from Azure AD, forwards them to AD DS, and, if the authentication is successful,
returns the response to Azure AD. You can configure SSO in combination with pass-through
authentication, which eliminates additional password prompts when on-premises users access
cloud applications. However, pass-through authentication is applicable only to web browser–based
applications and Microsoft Office 2013 or newer programs that support modern authentication.
Active Directory synchronization and Azure AD

To implement the synchronization process
(mentioned when discussing Azure AD DS and
Azure AD identity support), use Azure AD Connect.
This tool automatically synchronizes objects (such
as users, groups, devices, or contacts) and their
attributes from on-premises AD DS to Azure AD.
The synchronization process includes the User
Principal Name attribute, typically the same as the
user’s email address. This improves the sign-in
experience by ensuring that users can authenticate
by specifying a familiar user name when they
access the cloud services. The option of
synchronizing password hashes, which results in having a matching set of credentials in both directories,
is also available.
To enable users to sign in to Azure AD and on-premises Active Directory with the same credentials, the
domain name of Azure AD and on-premises Active Directory must match. This requires assigning and
validating a custom domain name to the Azure AD tenant, with which on-premises Active Directory
synchronizes.
An Azure AD environment with directory synchronization in place includes three types of users:
 Cloud-based users without password hash synchronization. In this scenario, directory

synchronization synchronizes user account information to Azure AD but excludes password
hashes. When passwords for Active Directory users change, this does not affect passwords for
the corresponding Azure AD users. This typically results in sign-in errors for the users and an
increased number of calls to the help desk. In this scenario, Azure AD handles authentication when
users attempt to access cloud-based resources.
 Cloud-based users with password hash synchronization. In this scenario, directory synchronization
synchronizes user account attributes and password hashes to Azure AD. This method ensures that
passwords of users in the scope of synchronization are the same in Azure AD and in on-premises
AD DS. This eliminates the problem from the first scenario, although users are typically prompted to
provide their password more than once. In this case, Azure AD also handles authentication to cloud-
based resources.
 Federated users. In this scenario, directory synchronization synchronizes user account information to
Azure AD. Azure AD uses the synchronized information to redirect users’ authentication 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.
Note: By implementing Azure AD pass-through authentication with the Seamless Single

Sign-On feature, you can eliminate multiple password prompts for on-premises users, without
relying on STS. This applies to scenarios where users access cloud applications via a web browser
or from the Microsoft Office programs that support modern authentication. For more details
regarding this functionality, refer to: “User sign-in with Azure Active Directory Pass-through
Authentication” at: https://aka.ms/dked64
Demonstration: Creating and managing an Azure AD tenant

 Create an Azure AD tenant, assign to it a custom domain, and view the verification DNS records.
 Associate an Azure AD instance with the current Azure subscription.

 Create an Azure AD user account.
 Grant an Azure AD user administrative access to an Azure subscription by assigning the owner
permissions on the subscription level.
Additional Reading: For detailed information on creating or editing users, refer to: “Add
new users to Azure Active Directory” at: https://aka.ms/fy887o
AD FS and Azure AD
As organizations move more services and
applications to cloud-based services, providing
a streamlined authentication and authorization
option to their users increases in importance.
You can use Windows Server Active Directory
Federation Services (AD FS) to provide a single
sign-on 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
Microsoft Exchange Online or Microsoft SharePoint
Online) that rely on Azure AD authentication, and
SaaS applications integrated with Azure AD.
Note that this functionality also requires directory synchronization between the on-premises Active
Directory and the corresponding Azure AD tenant, just like the sign-on methods described earlier.
However, you must also deploy a Security Token Service (STS) server role infrastructure, such as Windows
Server Active Directory Federation Services (AD FS). Because such servers must be able to communicate
directly with the AD DS domain controllers, they reside on the internal network. This means that you
must also deploy additional servers in your perimeter network that function as communication proxies
between the AD FS servers and the internet. You can implement them by using Windows Servers running
Web Application Proxy.
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 is 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 as part of 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.

Question
Which of the following are characteristics of Azure AD?
Multi-tenant
Contains organizational units
Uses LDAP for directory lookups
Supports Group Policy
Offers native support for Multi-Factor Authentication

Lesson 2
Manage Azure AD authentication
Azure AD enhances authentication security and improves the user sign-on experience by supporting
Multi-Factor Authentication and SSO. In this lesson, you will learn how to implement and take advantage
of both of these features.
Lesson Objectives
After completing this lesson, you should be able to:
 Describe the benefits of Multi-Factor Authentication that Azure AD provides.
 Describe the benefits of SSO that Azure AD provides.

 Configure Multi-Factor Authentication and SSO in Azure AD.
 Access SaaS applications via Access Panel.
Multi-Factor Authentication
The purpose of Multi-Factor Authentication is to
increase security. Traditional, standard
authentication requires knowledge of sign-in
credentials, typically consisting of a user name and
the associated password. Multi-Factor
Authentication adds an extra verification that relies
on either having access to a device that is
presumably in the possession of the rightful owner
or having physical characteristics of that person,
such as biometrics. This additional requirement
makes it considerably more difficult for an
unauthorized individual to compromise the
authentication process.
Microsoft Azure Multi-Factor Authentication

Microsoft Azure Multi-Factor Authentication is integrated into Azure AD. It allows the use of a
phone as the physical device providing a method of confirming the user’s identity. The process of
implementing Multi-Factor Authentication for an Azure AD user account starts when a user with the
Global Administrator role enables the account for Multi-Factor Authentication from the Azure portal. At
the next sign-in attempt, the user receives a prompt to set up the authentication by selecting one of the
following options:
 Mobile phone. Requires the user to provide a mobile phone number. Verification can be in the form
of a phone call, at the end of which the user must press the # key, or a text message.
 Office phone. Requires setting the value of the OFFICE PHONE property of the user’s account in
Azure AD. The administrator must preconfigure this entry because the user cannot modify or provide
this entry at the time of verification.
 Mobile app. Requires the users to have a smart phone on which they must install and configure the
mobile phone app.
App passwords
As part of the verification process, the user can also generate app passwords. This is because the use of
Multi-Factor Authentication does not support traditional desktop applications such as Microsoft Outlook
2010 and Microsoft Lync 2010 or earlier, and mobile apps for email. The user can then assign randomly
generated app passwords to individual apps by using their respective configuration settings.
App passwords can be a potential security vulnerability. Therefore, as an administrator, you can prevent
directory users from creating app passwords. You also can invalidate all app passwords for an individual
user if the computer or device where the apps are installed is compromised.
Office 2013 and newer versions support modern authentication, which makes it possible to configure
them to work with Multi-Factor Authentication. This eliminates the need for using app passwords.
Additional Reading: For more information regarding modern authentication, refer to:
“Office 2013 modern authentication public preview announced” at: https://aka.ms/m37pjz
Once the verification process is complete, Multi-Factor Authentication status for the user changes from
enabled to enforced. The same verification process repeats during every subsequent authentication
attempt. The Additional security verification option that appears in the Access Panel reflects the
change in status. From the Access Panel, you can choose and configure a different verification
mechanism and generate app passwords.
Additional Reading: For more information about Azure Multi-Factor Authentication, refer
to: “What is Azure Multi-Factor Authentication?” at: http://aka.ms/Ddsfo9
Demonstration: Configuring and using Multi-Factor Authentication

In this demonstration, you will learn how to:
 Enable Multi-Factor Authentication for an Azure AD user account.
 Authenticate to the Azure portal as an Azure AD user with Multi-Factor Authentication enabled.
SSO via Access Panel

SSO allows users to access Azure AD applications
without having to provide 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 have been published to Azure AD. This
is accomplished by leveraging one of two distinct
abilities of Azure AD; the first provides secure
storage of user credentials, and the second relies
on support for federated trusts with other cloud
services and identity providers.
A large number of 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.
Additional Reading: To view all currently available commercial Azure AD applications, go

to the Azure Marketplace at http://aka.ms/Htfnef and click Azure Active Directory apps.
Once Azure AD administrators have assigned these applications to users and configured them for SSO,
they automatically appear in the Access Panel. Users can sign in to the Access Panel by providing their
Azure AD credentials. They will not receive a prompt for their credentials again when they start the
applications.
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 have the option to 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, the application provider relies on Azure AD to handle users’ authentication, and considers them
authenticated when they open the application.
 Linked SSO, with Azure AD leveraging a federated trust between the application and an SSO
provider, established by using an existing STS implementation such as AD FS. This is similar to the
second mechanism because no separate application credentials are involved. However, in this case,
when users access the Access Panel application, their authentication requests are handled by your
current SSO solution.
Note that 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 an on-premises installation of the
application proxy connector and enabling application proxy in Azure AD.
Demonstration: Configure Password-based SSO

In this demonstration, you will learn how to:
 Add a directory application.

 Assign a directory application to a user.
Question: How will your organization use Azure AD?

Lab: Create and manage Azure Active Directory tenants

Scenario
Now that you have deployed several services for Azure, you must secure access to them by provisioning
Azure AD user accounts for employees of A. Datum Corporation. The long-term plan is to synchronize
existing on-premises AD DS user accounts with the Azure AD Default Directory tenant associated with
your Azure subscription. However, you first should test Azure AD functionality by creating and deleting
Azure AD user accounts directly in the Default Directory tenant. You should also test RBAC by granting
subscription-wide permissions to one of these accounts.
You will also create a new Azure AD tenant to be used for further testing of Azure AD functionality, and
will assign a custom DNS domain name to it.
Objectives
 Created a user in an Azure Active Directory tenant.

 Assigned to the new Azure AD user the owner role in the Azure subscription.
 Created a new Azure AD tenant.
 Created a custom DNS domain name for the Azure AD tenant.
Lab Setup
User name: Admin
Password: Pa55w.rd

o User name: Admin
5. You also need to start MSL-TMG1 for Internet access.
Question: What role should you assign to a user account in the Azure AD directory instance to
enable the user to fully manage all of its objects?

Review Question
Question: What are some benefits of using Azure AD as an identity provider?
Tools
Azure AD Connect is the primary tool for performing directory synchronization.
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.

10979D ENU TrainerHandbook

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

10979D ENU TrainerHandbook

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: 10979D

Part Number: X21-56543

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 1: What is cloud computing? 1-2

Lesson 2: What is Azure? 1-7

Lesson 3: Managing Azure 1-15

Lab: Using the Azure portals 1-25

Module Review and Takeaways 1-27

Module 2: Microsoft Azure management tools

Lesson 1: What is Azure PowerShell? 2-2

Lesson 2: Azure SDK and Azure CLI 2-8

Lab: Using Microsoft Azure management tools 2-13

Module Review and Takeaways 2-14

Module 3: Virtual machines in Microsoft Azure

Lesson 2: Configuring disks 3-15

Lab: Creating a VM in Azure 3-22

Module 4: Web Apps and cloud services

Lesson 1: Creating and configuring web apps 4-2

Lesson 2: Deploying and monitoring web apps 4-10

Lesson 3: Creating and deploying PaaS cloud services 4-18

Lab: Web Apps and cloud services 4-23

Module Review and Takeaways 4-25

Module 5: Creating and configuring virtual networks

Lesson 1: Getting started with virtual networks 5-2

Lesson 2: Configuring Azure networking 5-7

Lesson 3: Getting started with Azure Load Balancer 5-11

Lab: Create and configure virtual networks 5-14

Module 6: Cloud storage

Lesson 1: Understanding cloud storage 6-2

Lesson 2: Create and manage storage 6-9

Lab: Configure Azure Storage 6-15

Module Review and Takeaways 6-17

Module 7: Microsoft Azure databases

Lesson 1: Understanding options for relational database deployments 7-2

Lesson 2: Creating and connecting to Azure SQL databases 7-6

Module Review and Takeaways 7-12

Module 8: Creating and managing Azure AD

Lesson 2: Manage Azure AD authentication 8-12

Lab: Create and manage Azure Active Directory tenants 8-15

About This Course

 Understanding of how to deploy websites.

 A basic understanding of virtualization.

 Describe cloud computing, Azure, and Azure subscriptions.

 Create and configure Azure virtual networks.

 Create, manage, and configure cloud storage in Azure.

 Create and manage Azure AD.

 Lab Answer Keys: provide step-by-step lab solution guidance.

Additional Reading: Course Companion Content on the http://www.microsoft.com

Virtual Machine Environment

Virtual Machine Configuration