20533C TrainerHandbook PDF

MCT USE ONLY.
STUDENT USE PROHIBITED

O F F I C I A L M I C R O S O F T L E A R N I N G P R O D U C T
20533C
Implementing Microsoft Azure
Infrastructure Solutions
MCT USE ONLY. STUDENT USE PROHIBITED
ii Implementing Microsoft Azure Infrastructure Solutions
Information in this document, including URL and other Internet Web site references, is subject to change
without notice. Unless otherwise noted, the example companies, organizations, products, domain names,
email addresses, logos, people, places, and events depicted herein are fictitious, and no association with
any real company, organization, product, domain name, email 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.
© 2016 Microsoft Corporation. All rights reserved.
Microsoft and the trademarks listed at http://www.microsoft.com/trademarks are trademarks of the

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

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

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

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

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

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

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

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

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

Implementing Microsoft Azure Infrastructure Solutions xi
xii Implementing Microsoft Azure Infrastructure Solutions
Acknowledgments
Microsoft Learning would like to acknowledge and thank the following for their contributions in this title’s
development. Their effort at various stages of development has ensured that you have a good classroom
experience.
Marcin Policht: Content Developer
Marcin Policht obtained his Master of Computer Science degree 18 years ago, and has since worked in
the Information Technology (IT) field, focusing primarily on directory services, virtualization, system
management, and database management. Marcin authored the first book dedicated to Windows
Management Instrumentation, and has 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.
Marjan Stamatovski: Content Developer

Marjan Stamatovski is a Microsoft Certified Trainer (MCT), Microsoft Certified Solutions Expert (MCSE),
Microsoft Certified IT Professional (MCITP), and is a senior consultant and trainer who has more than 20
years of professional experience in IT technology. He has been an MCT for more than 13 years, focusing
primarily on designing and implementing large computer networks based on Microsoft products. Marjan’s
areas of expertise include virtualization, and public and private clouds. As project manager for several
complex merging scenarios, mainly in the telecommunications area, Marjan has covered and supported a
wide range of Microsoft products with no downtime. Currently, Marjan is working as a senior trainer and
consultant on Microsoft Azure, Office 365, Intune, and System Center products.
Jason Kellington: Content Developer

Jason Kellington (MCT, MCSE, and MCITP) is a consultant, trainer, and author. He has experience working
with a wide range of Microsoft technologies, focusing on enterprise network infrastructure. Jason works in
several capacities with Microsoft. He is a content developer for Microsoft Learning courseware titles, a
senior technical writer for Microsoft IT Showcase, and an author for Microsoft Press.
Telmo Sampaio: Technical Reviewer

Telmo Sampaio is a Sr. Program Manager for the Azure CAT group at Microsoft, where he specializes in
identifying patterns and creating guidance for Azure customers. He is a trainer, architect, developer,
consultant, author, and speaker at events such as Ignite, Build, TechEd, MMS, and PASS. Telmo is very
active in the MCT community, being one of the first MCT Regional Leads.
Implementing Microsoft Azure Infrastructure Solutions xiii
Contents
Module 1: Introduction to Microsoft Azure
Module Overview 1-1
Lesson 1: Cloud technology overview 1-2
Lesson 2: Overview of Azure 1-6
Lesson 3: Managing Azure with the Azure portal 1-17
Lesson 4: Managing Azure with Windows PowerShell 1-21
Lesson 5: Overview of Azure Resource Manager 1-28
Lesson 6: Azure management services 1-33
Lab: Managing Microsoft Azure 1-38
Module Review and Takeaways 1-43
Module 2: Implementing and managing Azure networking

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

Azure virtual networks 2-25
Lesson 3: Configuring Azure virtual network 2-29
Lesson 4: Configuring virtual network connectivity 2-39

Lesson 5: Overview of Azure networking in IaaS v1 2-50
Lab B: Configuring connectivity between IaaS v1 and IaaS v2 2-58
Module 3: Implementing virtual machines

Module Overview 3-1
Lesson 1: Overview of IaaS v2 virtual machines 3-2
Lesson 2: Planning for Azure Virtual Machines 3-7
Lesson 3: Deploying IaaS v2 virtual machines 3-15
Lab A: Creating IaaS v2 virtual machines in Azure 3-22
Lesson 4: Authoring Azure Resource Manager templates 3-25
Lab B: Deploying IaaS v2 virtual machines by using Azure Resource Manager

templates 3-37

xiv Implementing Microsoft Azure Infrastructure Solutions

Module Overview 4-1
Lesson 1: Configuring virtual machines 4-2
Lesson 2: Configuring virtual machine disks 4-11
Lesson 3: Managing and monitoring Azure virtual machines 4-17
Lesson 4: Managing IaaS v1 virtual machines 4-28
Lab: Managing Azure virtual machines 4-32
Module 5: Implementing Azure App Service

Module Overview 5-1
Lesson 1: Introduction to App Service 5-2
Lesson 2: Planning app deployment in App Service 5-12
Lesson 3: Implementing and maintaining web apps 5-16

Lesson 4: Configuring web apps 5-24
Lesson 5: Monitoring web apps and WebJobs 5-33
Lesson 6: Implementing mobile apps 5-38

Lesson 7: Traffic Manager 5-43
Lab: Implementing web apps 5-50
Module 6: Planning and implementing storage, backup, and recovery services

Module Overview 6-1
Lesson 1: Planning storage 6-2
Lesson 2: Implementing and managing Azure Storage 6-10

Lesson 3: Implementing Azure content delivery networks 6-22
Lesson 4: Implementing Azure Backup 6-27
Lesson 5: Planning and implementing Azure Site Recovery 6-34
Lab: Planning and implementing Azure Storage 6-40

Implementing Microsoft Azure Infrastructure Solutions xv
Module 7: Planning and implementing Azure SQL Database

Module Overview 7-1
Lesson 1: Planning and deploying Azure SQL Database 7-2
Lesson 2: Implementing and managing Azure SQL Database 7-10
Lesson 3: Managing Azure SQL Database security 7-16
Lesson 4: Monitoring Azure SQL Database 7-24
Lesson 5: Managing Azure SQL Database business continuity 7-29
Lab: Planning and implementing Azure SQL Database 7-34
Module 8: Implementing PaaS cloud services

Module Overview 8-1
Lesson 1: Planning and deploying PaaS cloud services 8-2
Lesson 2: Managing and maintaining cloud services 8-11

Lab: Implementing PaaS cloud services 8-20
Module 9: Implementing Azure Active Directory

Module Overview 9-1
Lesson 1: Creating and managing Azure AD tenants 9-2
Lesson 2: Configuring application and resource access with Azure AD 9-14
Lesson 3: Overview of Azure AD Premium 9-23

Lab: Implementing Azure AD 9-31
Module 10: Managing an Active Directory infrastructure in a hybrid

environment
Module Overview 10-1
Lesson 1: Extending an on-premises Active Directory domain to Azure 10-2
Lesson 2: Implementing directory synchronization by using

Azure AD Connect 10-9
Lesson 3: Implementing federation 10-27
Lab: Implementing and managing Azure AD synchronization 10-36

xvi Implementing Microsoft Azure Infrastructure Solutions
Module 11: Implementing Azure-based management and automation

Lesson 1: Implementing OMS 11-2
Lesson 2: Implementing Azure Automation 11-9
Lesson 3: Implementing Automation runbooks 11-16
Lesson 4: Managing Azure Automation 11-24
Lab: Implementing Automation 11-29
Lab Answer Keys

Module 1 Lab: Managing Microsoft Azure L1-1
Module 2 Lab A: Using a deployment template and Azure PowerShell to

implement Azure virtual networks L2-7
Module 2 Lab B: Configuring connectivity between IaaS v1 and IaaS v2 L2-11

Module 3 Lab A: Creating IaaS v2 virtual machines in Azure L3-19
Module 3 Lab B: Deploying IaaS v2 virtual machines by using Azure

Resource Manager templates L3-21
Module 4 Lab: Managing Azure virtual machines L4-27
Module 5 Lab: Implementing web apps L5-37
Module 6 Lab: Planning and implementing Azure Storage L6-45
Module 7 Lab: Planning and implementing Azure SQL Database L7-53
Module 8 Lab: Implementing PaaS cloud services L8-61
Module 9 Lab: Implementing Azure AD L9-69

Module 10 Lab: Implementing and managing Azure AD synchronization L10-79
Module 11 Lab: Implementing Automation L11-85

About This Course xvii
About This Course

This section provides a brief description of your course, including about the audience, suggested
prerequisites, and course objectives.
Course Description
This course teaches information technology (IT) professionals how to provision and manage services in
Microsoft Azure (Azure). Students will learn how to implement infrastructure components, such as virtual
networks, virtual machines (VMs), web and mobile apps, and storage in Azure. Students also will learn how
to plan for, and manage, Azure Active Directory (Azure AD), and configure Azure AD integration with on-
premises Active Directory domains.
Audience
This course is for IT professionals who are familiar with managing on-premises IT deployments that
include Active Directory Domain Services (AD DS), virtualization technologies, and applications. Students
typically work for organizations that are planning to locate some or all of their infrastructure services on
Azure. This course also is for IT professionals who want to take the Microsoft Certification exam, 70-533,
Implementing Microsoft Azure Infrastructure Solutions.
Student Prerequisites
In addition to their professional experience, students who attend this training should have the following
technical knowledge, including an understanding of:
• On-premises virtualization technologies, including virtual machines, virtual networking, and virtual
hard disks.
• Network configuration, including TCP/IP, Domain Name System (DNS), virtual private networks,
firewalls, and encryption technologies.
• Websites, including create, configure, monitor, and deploy a website on Internet Information Services
(IIS).
• Active Directory concepts, including domains, forests, domain controllers, replication, Kerberos
version 5 protocol, and Lightweight Directory Access Protocol (LDAP).
• Database concepts, including tables, queries, Structured Query Language (SQL), and database
schemas.
• Understanding of resilience and disaster recovery, including backup and restore operations.
Course Objectives
After completing this course, students will be able to:
• Describe Azure architecture components, including infrastructure, tools, and portals.
• Implement and manage virtual networking within Azure and to connect to on-premises
environments.
• Plan and create Azure virtual machines.
• Configure, manage, and monitor Azure virtual machines to optimize availability and reliability.
• Deploy and configure websites.
• Implement, manage, backup, and monitor storage solutions.
• Support applications by planning and implementing data services based on SQL Database.
• Deploy, configure, monitor, and diagnose cloud services.
xviii About This Course
• Create and manage Azure AD directories, and configure application integration with Azure AD.
• Integrate on-premises Windows AD with Azure AD.
• Automate operations in Azure management by using Windows PowerShell runbooks.
• Use all the information obtained in this course to plan and execute an Azure migration project.
Course Outline
The course outline is as follows:
• Module 1: “Introduction to Microsoft Azure” introduces cloud solutions in general, and then it focuses
on the services that Azure offers. The module goes on to describe the portals that you can use to
manage Azure subscriptions and services before introducing Windows PowerShell as a scripting
solution for managing Azure. Finally, the module provides explanations and guidance for the use of
Azure Resource Manager and Azure management services.
• Module 2: “Implementing and managing Azure networking” explains how virtual networking provides
the glue that binds together VMs, web apps, and storage to enable you to publish a service onto the
Internet. The module provides details on how to implement networking in Azure.
• Module 3: “Implementing virtual machines” explains how to implement virtual machines including
infrastructure as a service (IaaS) version 1 (v1) and version 2 (v2) VMs, planning for Azure virtual
machines, deploying IaaS v2 VMs, and authoring Azure, Resource Manager templates.
• Module 4: “Managing virtual machines” explains how to manage virtual machines including
configuring virtual machines, configuring virtual machine disks, and managing and monitor virtual
machines.
• Module 5: “Implementing Azure App Service” explains how to implement Azure Web App services.
This module explains the different types of apps that you can create by using the Microsoft Azure
App Service, and how you can select an App Service plan and deployment method for apps in
Microsoft Azure. Students will learn how to use Microsoft Visual Studio, File Transfer Protocol (FTP)
clients, and Azure PowerShell to deploy web and mobile apps to Azure. Additionally, they will learn
how to configure web apps and use the Azure WebJobs feature to schedule tasks, monitor the
performance of web apps, and create and configure mobile apps. Lastly, they will learn how to use
Azure Traffic Manager to distribute requests between two or more app services.
• Module 6: “Planning and implementing storage, backup, and recovery services” explains how to plan
and implement storage, backup, and recovery services. Students will learn how to choose appropriate
Microsoft Azure Storage options to address business needs. This module also explains how to
implement and manage Azure Storage, and students will learn how to improve web-application
performance by implementing Azure Content Delivery Networks (CDNs). Lastly, they will learn how to
protect on-premises systems and Azure VMs by using Azure Backup, and they will be able to describe
Azure Site Recovery capabilities.
• Module 7: “Planning and implementing Azure SQL Database” explains how to plan and implement
Azure SQL Database, and identify relational database services in Microsoft Azure. This module
explains how to provision, configure, and manage the Azure SQL Database data-management service.
Students will learn how to configure security for Azure SQL Database and monitor Azure SQL
Database, as well as manage data recovery and availability for Azure SQL Database.
• Module 8: “Implementing PaaS cloud services” explains how to implement platform as a service
(PaaS) cloud services. This module also explains how to plan and deploy a platform as a service (PaaS)
cloud service in Microsoft Azure. Students will learn how to configure PaaS cloud services by using
configuration files or the Azure portal, and how to monitor the performance of cloud services and
diagnose bottlenecks.
About This Course xix
• Module 9: “Implementing Azure Active Directory” explains how to implement Azure AD. Students will
learn how to create and manage Azure AD tenants. This module also explains how to configure single
sign-on (SSO) for cloud applications and resources, and implement Azure Role-Based Access Control
(RBAC) for cloud resources. Lastly, this module explains the functionality of Azure AD Premium, and
how to implement Azure Multi-Factor Authentication.
• Module 10: “Managing an Active Directory infrastructure in a hybrid environment” explains how to
manage Active Directory in a hybrid environment. Students will learn how to extend an on-premises
Active Directory domain to Microsoft Azure and synchronize user accounts between on-premises AD
DS and Azure AD. This module also explains how to set up SSO by using federation between on-
premises Active Directory and Azure AD.
• Module 11: “Implementing Azure-based management and automation” This module explains how to
implement Azure-based management and automation. Students will learn how to implement
Microsoft Operations Management Suite (OMS) solutions and the core components of Microsoft
Azure Automation. This module also describes how to implement different types of Azure
Automation runbooks and manage Azure Automation by publishing runbooks and scheduling their
execution.
xx About This Course
Course Materials
Your kit includes the several pieces, including the:
• Course Handbook: This is a succinct classroom learning guide that provides the critical technical
information in a crisp, tightly-focused format, which is essential for an effective in-class learning
experience. It includes the following sections:
o Lessons: These guide you through the learning objectives and provide the key points that are
critical to the success of the in-class learning experience.
o Labs: These provide a real-world, hands-on platform on which you can apply the knowledge and
skills that you have learned in the module.
o Module Reviews and Takeaways: These provide on-the-job reference material to boost
knowledge and skills retention.
o Lab Answer Keys: These provide step-by-step lab-solution guidance.
Additional Reading: Course Companion Content: This is searchable, easy-to-browse

digital content with integrated premium online resources that supplement the Course Handbook.
• Modules: These include companion content for each lesson, including questions and answers,
detailed demonstration steps, and additional reading links. Additionally, they include Lab Review
questions and answers, and Module Reviews and Takeaways sections, which contain the review
questions and answers, best practices, common issues and troubleshooting tips with answers, and
real-world issues and scenarios with answers.
• Resources: These include well-categorized additional resources that give you immediate access to
the most current premium content on TechNet, MSDN, or Microsoft Press.
Additional Reading: Student Course files on the

http://www.microsoft.com/learning/en/us/companion-moc.aspx Site: These include the
Allfiles.exe, a self-extracting executable file that contains all required files for the labs and
demonstrations.
• Course evaluation: This is at the end of the course, and provides you with the opportunity to
complete an online evaluation that provides feedback on the course, training facility, and instructor.
o To provide additional comments or feedback on the course, send an email to

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

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

• Student will be provided with an Azure Learning Pass before course starts.
• Classroom PC (Hardware Level 7, dual monitors) with a student Hyper-V classroom image based on
Windows 10 Enterprise. Differencing drive includes the software listed in Table 1 and lab files listed in
table 2.
To set up requirements, students run provisioning scripts at the beginning of each lab. The beginning of
each lab plan in this document lists these requirements. Students will execute deprovisioning scripts at the
end of each lab, to remove all changes that they have made. In this way, scripts ensure that each lab does
not depend on the students correctly executing previous labs.
This course will be delivered worldwide, and instructors should be able to choose regions close to their
physical location. Two regions must be selected: an HQ Region and a Branch Region. Every provisioning
script must request, from the user, the regions in which to configure Azure objects. The lab instructions
use the HQ Region and Branch Region placeholders.
The following table shows the role of each virtual machine that this course uses.
Virtual machine Role
20533C-MIA-CL1
Software Configuration
The following software is installed on each VM:
• Microsoft SQL Server 2014 Enterprise
• Windows Azure Storage Emulator – v3.4

• Windows Phone 8.1 Emulators - ENU
• Microsoft Azure SDK 2.5
• Windows Azure Active Directory Module for Windows PowerShell
• Azure PowerShell
• MAP Toolkit 9.1
• Azure Cross Platform Command Line Interface
• Puppet
• Chef
Course Files
The files associated with the labs in this course are located in the C:\Labfiles\LabXX folder on the student
computers.
Classroom Setup
Each classroom computer will have the same virtual machine with the same configuration.
xxii About This Course
Course Hardware Level

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

Lab: Managing Microsoft Azure 1-38
Module Overview
Organizations are increasingly moving IT workloads to the cloud, so IT professionals need to understand
the principles that form the basis of cloud solutions and learn how to deploy and manage cloud apps,
services, and infrastructure. In particular, IT professionals who are planning to use Microsoft Azure must
learn about the services that Azure provides and how to manage them.
This module introduces cloud solutions in general and then focuses on the services that Azure offers. The
module goes on to describe the portals that you can use to manage Azure subscriptions and services
before introducing Windows PowerShell as a scripting solution for managing Azure. Finally, the module
provides explanations and guidance for the use of Azure Resource Manager and Azure management
services.
Objectives
After completing this module, you will be able to:
• Identify suitable apps for the cloud.
• Identify the services and capabilities that Azure provides.
• Use Azure portals to manage Azure services and subscriptions.
• Use Windows PowerShell to manage Azure services and subscriptions.
• Use Azure Resource Manager to manage Azure resources.
• Use Azure management services to extend the management and monitoring of Azure.
1-2 Introduction to Microsoft Azure
Lesson 1
Cloud technology overview
Cloud computing plays an increasingly important role in IT infrastructure, and IT professionals need to be
aware of fundamental cloud principles and techniques. This lesson introduces the cloud and describes the
considerations for implementing cloud-based infrastructure services.
Lesson Objectives
After completing this lesson, you will be able to:
• Prepare the environment.
• Describe the key principles of cloud computing.

• Identify common types of cloud services.
Demonstration: Preparing the environment

In this demonstration, you will see how to prepare the Azure environment.
Demonstration Steps
1. On the taskbar, right-click Windows PowerShell, and then click Run as administrator. In the User
Account Control dialog box, click Yes.
2. Type the following command, and then press Enter:
Setup-Azure
3. At the command prompt, type 1, and then press Enter.

4. Confirm your selection, and then press Enter.
Introduction to cloud computing

Cloud computing, or the cloud, has become a
leading trend in IT. However, its definition is
ambiguous, and some of the terminology related
to it is confusing. Trying to define the cloud in
purely technological terms is difficult—it is best
to think of it as being an abstract concept that
encapsulates techniques used to provide
computing services from a pool of shared
resources.
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 layers of abstraction to define
specific services that you can provision and use.
Implementing Microsoft Azure Infrastructure Solutions 1-3
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
characteristics:
• On-demand self-service. Cloud services are generally provisioned as they are required and need
minimal infrastructure configuration by the consumer. As a result, users of cloud services can quickly
set up the resources they want, typically without having to involve IT specialists.
• Broad network access. Consumers generally access cloud services over a network connection, usually
either a corporate network or the Internet.
• Resource pooling. Cloud services use a pool of hardware resources that consumers share. A hardware
pool consists of hardware from multiple servers that are arranged as a single logical entity.
• Rapid elasticity. Cloud services scale dynamically to obtain additional resources from the pool as
workloads intensify, and they release resources automatically when no need for them exists.
• Measured service. Cloud services generally include a metering capability, making it possible to track
relative resource usage by the users of the services, or subscribers.
Advantages of cloud computing

Cloud computing has several advantages over traditional, datacenter-based computing, including the
following:
• A managed datacenter. With cloud computing, your service provider can manage your datacenter.
This obviates the need for you to manage your own IT infrastructure. With cloud computing, you can
also access computing services irrespective of your location and the hardware that you use to access
those services. Although the datacenter remains a key element in cloud computing, the emphasis is
on virtualization technologies that focus on delivering apps rather than on infrastructure.
• Lower operational costs. Cloud computing provides pooled resources, elasticity, and virtualization
technology. These factors help you to alleviate issues such as low system use, inconsistent availability,
and high operational costs. It is important to remember that with cloud computing, you pay for only
the services that you use; this can mean substantial savings on operational costs for most
organizations.
• Server consolidation. You can consolidate servers across the datacenter by using the cloud computing
model, because it can host multiple virtual machines on a virtualization host.
• Better flexibility and speed. When you use the cloud computing model with products such as
Microsoft System Center 2012 R2, you can increase resources’ flexibility and the speed of access to
resources.
Public, private, and hybrid clouds

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

Cloud services generally fall into one of the
following three categories:
• Software as a Service (SaaS)
• Platform as a Service (PaaS)

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

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

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

Datacenters managed by Microsoft host Azure
services throughout the world. Whenever you
create a new Azure service, you must select an
Azure region to determine the datacenter where
the service will run. When you select an Azure
region, you should consider where the users of
that service are located and place the service as
close to them as possible. Some services enable
you to serve content from more than one Azure
region. In this way, you can serve content to a
truly global audience while helping to ensure that
a local response gives them the highest possible
performance. The datacenters are located in the following geographic areas:
• West Europe
• East Asia
• Central US
• East US
• East US 2
• West US
• North Central US
• South Central US
• North Europe
• Southeast Asia
• Japan West
• Japan East
• Brazil South
• Australia East
• Australia Southeast
• South India
• Central India
• West India
A range of architectures that spans several generations and is continually evolving forms the basis of these
datacenters. The latest generation of datacenters has as its basis a fully modular design that includes the
following features:
• Clusters of servers are packaged into preassembled units based on shipping containers, enabling
clusters that contain thousands of servers to be rapidly provisioned and swapped out.
• The datacenters include uninterruptable power supplies and alternate power supplies for all
components, in addition to backup power that can keep the datacenter running in the event of a
localized disaster.
• The clusters within datacenters are connected by redundant high-speed networks.
• The datacenters are connected to one another and the Internet via high-speed optical networks.
• The data within a single datacenter can be replicated to three redundant storage devices and also
between pairs of datacenters in the same geographic region.
• The physical and network security for Azure datacenters meets a range of industry and government
standards.
The datacenters are designed to minimize power and water usage for maximum efficiency, including
servers and other hardware, cooling, and support operations.
The servers in each datacenter are provisioned in clusters, and each cluster includes multiple racks of
servers that run Windows Server 2012 R2. A distributed service application, named Azure Service Fabric,
manages provisioning, dynamic scaling, and hardware fault management for the virtual servers that host
cloud services on the physical servers in the cluster.
Additional Reading: For more information, refer to Azure Regions: http://aka.ms/Ym4ryz.

Understanding Azure services

Azure provides a wide range of cloud-based
services that you can use as components for
customized cloud solutions and infrastructure:
• Compute:
o Azure Virtual Machines. Create Windows

and Linux virtual machines from
predefined templates, or deploy your
own custom server images in the cloud.
o Azure Cloud Services. Define multi-tier

PaaS cloud services that you can deploy
and manage on Azure.
o Azure Batch. Run high volume, large-scale parallel and high-performance computing apps on a
scaled and managed set of virtual machines.
o Azure RemoteApp. Provision Windows apps on Azure and run them from essentially any device.
o Service Fabric. Manage and build Azure components.
• Web & Mobile:
o Azure App Service. Integrate and manage web and mobile app solutions with:
 The Logic Apps feature in Azure App Service. Automate running business processes and
workflows.
 The Web Apps feature in Azure App Service. Deploy web apps to the cloud.
 Azure Mobile Services. Develop highly scalable, globally available mobile apps.
 Azure API Management. Provide the building blocks for integrating and building new apps.
o Notification Hub. Create push notifications for apps and services.
o Azure Mobile Engagement. Use app analytics and app messaging to engage mobile app users.
• Data & Storage:
o Azure DocumentDB. Implement a NoSQL data store for your apps.
o SQL Database. Implement relational databases for your apps without the need to provision and
manage a database server.
o Azure Redis Cache. Implement high-performance caching solutions for your apps.
o Azure Storage. Store data in files, binary large objects (BLOBs), tables, and queues.
o StorSimple. Manage the storage between on-premises and cloud storage.
o Azure Search. Provide a fully managed search service.
o SQL Data Warehouse. Store and access large scale, distributed data.
• Analytics:
o Azure HDInsight. Provision Apache Hadoop clusters in the cloud.
o Azure Machine Learning. Run predictive analytics and forecasting from existing data.
o Azure Stream Analytics. Set up real-time data analysis from many sources.
o Azure Data Factory. Create data pipelines by using data storage, data processing services, and
data movement.
o Azure Event Hubs. Receive and process massive amounts of data from connected devices and
apps.
o Azure Data Catalog. Implement the registration and discovery of enterprise data sources.
o Azure Data Lake Store. Create hyperscale repositories for big data analytics.
o Azure Data Lake Analytics. Run large-scale data analysis jobs.

• Networking:
o Azure Virtual Network. Connect and segment the cloud infrastructure.
o Azure ExpressRoute. Extend your enterprise to Azure through a dedicated private connection.
o Application Gateway. Build a scalable network capability for applications.
o Azure Traffic Manager. Implement load balancing for high scalability and availability.
o Azure-provided DNS. Host and manage your DNS domain and records for use with Azure apps.
o Load Balancer. Create highly available and high-performance cloud-based networks.
o VPN Gateway. Create network connections between Azure and on-premises networks.
• Media & Azure Content Delivery Network:

o Azure Media Services. Deliver multimedia content, such as video and audio.
o Content Delivery Network. Distribute content to users throughout the world.
• Hybrid Integration:
o Azure BizTalk Services. Build integrated business orchestration solutions that integrate enterprise
apps with cloud services.
o Azure Service Bus. Connect apps across on-premises and cloud environments.
o Azure Backup. Back up virtual machines and send backup data to Azure for retention and
recovery.
o Azure Site Recovery. Create and implement disaster recovery solutions for the cloud and on-
premises infrastructure.
• Identity and Access Management:
o Azure AD. Integrate your corporate directory with cloud services for a single sign-on (SSO)
solution.
o Azure Multi-Factor Authentication. Implement additional security measures in your apps to verify
user identity.
o Azure AD DS. Host domain controller functionality in the cloud.
o Azure AD B2C. Provide scalable identity and access management solutions for customer-facing
apps.
• Developer Services:
o Visual Studio Application Insights. Provide a cloud-based analysis and diagnosis of app usage.
o Azure DevTest Labs. Create, monitor, and manage virtual machines in a dedicated test
environment.
• Management:
o Key Vault. Track and manage cryptographic information.
o Scheduler. Create and schedule automation of cloud services.
o Automation. Automate long-running, frequently repeated, and time-consuming tasks.
o Operational Insights. Use machine data to build operational intelligence.
o Azure Internet of Things (IoT) Hub. Enable and encrypt communications between IoT connected
devices and apps.
o Security Center. Monitor and manage control of and access to Azure resource security.
Note: Azure is continually being improved and enhanced, and new services are added on a
regular basis.
Additional Reading: For more information, refer to The cloud for modern business:
http://aka.ms/Gcdrky.
Compute hosting options provided by Azure

Azure provides several options to provide apps
and compute-based services from the cloud. The
five functional components for providing apps
from within Azure are:
• App Service and App Service Environment

• Azure Cloud Services
• Azure Virtual Machines
• Azure Service Fabric
• Azure Container Service
App Service and App Service Environment

You can use App Service to quickly provision and create web apps in Azure. App Service is a PaaS solution,
so App Service solutions run in a virtual machine environment. Therefore, the infrastructure and operating
system details and management are virtualized and transparent to the app that Azure hosts. You can
create App Service solutions by using Microsoft ASP.NET, PHP, Node.js, and Python. Web apps that use
App Service can also integrate with other Azure services, including SQL Database, Service Bus, or BLOB
storage. By using multiple copies of an app inside separate virtual machines, you can rapidly provision and
scale web apps that use App Service. Because virtual machines are already in place, provisioning a web
app takes significantly less time than a virtual machine. You can publish code for App Service apps by
using the Microsoft Web Deployment Tool (Web Deploy), Microsoft Visual Studio, Git, GitHub, File
Transfer Protocol (FTP), Bitbucket, CodePlex, Mercurial, Dropbox, Microsoft Team Foundation Server, and
the cloud-based Team Foundation Service from Visual Studio Online. You can also migrate existing on-
premises sites to Azure by using existing tools and guidance, which later modules in this course cover.
You can also use Azure App Service Environment to create a dedicated environment in which you can run
Azure apps such as Web apps, Mobile apps, and Logic apps. Apps within an App Service Environment can
connect to each other inside a virtual network that defines the network scope of the App Service
Environment.
Azure Cloud Services

With Azure Cloud Services, you can extend the functionality of your cloud-based solution. Azure Cloud
Services supports scalability for apps and greater control over the hosting environment. When using Azure
Cloud Services, you can connect to your virtual machines and perform simple management tasks, such as
app installation. You typically use Azure Cloud Services to deploy more complex solutions than an App
Service web app can provide. Azure Cloud Services is best suited to:
• Multi-tiered web apps.

• Web apps that require a highly scalable, high-performance environment.
• Web apps that have relatively simple additional requirements, such as secondary apps or minor
environment changes.
Azure Virtual Machines

Azure Virtual Machines provides the greatest flexibility and control of the available compute options. As
an IaaS solution, Azure Virtual Machines operates in much the same way as Microsoft Hyper-V virtual
machines on Windows Server 2012 R2. You have complete control over the virtual machine at the
operating system level, and you also must maintain the virtual machine at the operating system level,
including maintaining business continuity and installing updates. You can choose to start from scratch and
install a supported operating system of your choice, or you can choose from one of the virtual machine
images available in Azure. You can also create virtual machines by importing existing Hyper-V virtual
machines from your on-premises virtualization infrastructure. Azure Virtual Machines is best suited to:
• Highly customized apps that require complex infrastructure components.
• Hosting Windows Server or Linux apps and infrastructure servers, such as domain controllers, DNS
servers, or database servers.
Azure Service Fabric

Service Fabric provides a reliable and flexible technology that you can use to build apps. Service Fabric
supports both stateful and stateless apps. Service Fabric apps are composed of microservices running on a
shared pool of computers referred to as a Service Fabric cluster. Service Fabric is primarily used to build
complex cloud apps, and it is used to power such Microsoft services as Microsoft Intune, Skype for
Business, and Cortana.
Azure Container Service

With Azure Container Service, you can create clusters to support apps. Although Azure Container Service
is new, it is positioned to enable enterprises to build rapidly scalable clustered apps. Azure Container
Service supports Mesos clusters and Docker-based apps.
Understanding the Azure service model

Multi-tenancy within a scalable and highly
available cloud-based infrastructure forms the
basis of the Azure service model. A subscription
model that dictates the level of access a subscriber
has to Azure and the billing structure in place for
the subscriber together define that subscriber’s
access to Azure services. Azure services are
primarily pay-per-use, with subscribers using
different services and functionalities in Azure and
paying for the cloud resources that these services
and functionalities consume.
Accounts and subscriptions

An Azure account determines how and to whom your Azure usage is reported. With a subscription, you
can organize your access to your cloud services and resources. A subscription helps you to control how
your resource usage is reported, billed, and paid for.
Each of your subscriptions can have a different billing and payment setup. As a result, you can have
different subscriptions and different plans by department, project, regional office, or other factors. Every
cloud service belongs to a subscription, and the subscription ID is often required for some operations.
Signing in to Azure
To manage Azure, you must sign in by using a user ID, which takes the form of an email address. Two
types of user IDs exist:
• Microsoft accounts. These take the form of user@outlook.com, user@hotmail.com, or something

similar.
• Organizational accounts. These take the form of user@contoso.onmicrosoft.com or

user@contoso.com.
Organizational accounts differ from Microsoft accounts because they are based in Azure AD. As a result,
you have more options for managing organizational accounts. For example, you can supplement
organizational accounts with multi-factor authentication, which requires the user to enter additional
information to verify his or her identity. Generally, you should use organizational accounts whenever you
need to assign administrative access to Azure. Every Azure subscription has a default directory that you
can use to create organizational accounts.
Pricing and billing

Five pricing options for Azure exist:
• Pay-As-You-Go. Choose this option if you want a flexible pricing plan. You pay only for the services
you use. You can cancel this subscription at any time. You can make payments only by using credit or
debit cards. It is important to note that usage quotas apply to this plan, including limits on cloud
services, virtual machines, storage, and Azure AD.
Additional Reading: For more information, refer to Pay-As-You-Go: http://aka.ms/Uis9fx.

• Annual prepaid subscription. Prepaid subscriptions carry the same billing model as Pay-As-You-Go
subscriptions but with an additional five percent discount on Azure services and a minimum prepay
cost.
Additional Reading: For more information, refer to 12-Month Prepay Offer:

http://aka.ms/M22av1.
• Buying from a Microsoft reseller. To work with the same resellers from whom you currently purchase
Microsoft software under the Microsoft Open License program, you can select this option. You must
purchase Azure in Open credits from your vendor. You can then activate your subscription by using
those credits. You can apply Azure in Open credits toward any Azure service that is eligible for
monetary commitments when purchased online. Services that are not eligible for use with monetary
commitments, such as Azure Rights Management Services and Azure AD Premium, cannot be
procured by using Azure in Open.
Additional Reading: For more information, refer to Get Started with Azure in Open
Licensing: http://aka.ms/Mq0oy5.
• Enterprise Agreement. This option is best suited to large organizations that sign an Enterprise
Agreement and make an upfront commitment to purchase Azure services. Customers who select this
option can use the Azure Enterprise Portal to administer their subscription. Microsoft bills these
customers annually, based on their service usage. This can make it easier to accommodate unplanned
growth.
Additional Reading: For more information, refer to Licensing Azure for the Enterprise:
http://aka.ms/Br93cj.
• Azure Compute Option. The Azure Compute Option is designed to ease the transition from an on-
premises infrastructure to Azure. This option provides discounted hours for compute services when
you purchase add-ons to your Windows Server annuity licenses. The discount increases with the
number of add-ons purchased.
Additional Reading: For more information, refer to Microsoft Azure Compute Option:
http://aka.ms/Cqueg2.
Support plans
You can also purchase support plans from Microsoft that provide varying levels of support for your Azure
environment. You can choose from one of four support plans:
• Developer. The Developer plan is designed for test or nonproduction environments and includes all
day, every day technical support for Azure with a minimum initial response time of less than eight
hours.
• Standard. The Standard plan offers the same features as the Developer plan, and the initial response
time is reduced to less than two hours.
• Professional Direct. This plan is designed for organizations that depend on Azure for business-critical
apps or services, and it includes everything in the Standard plan in addition to basic advisory services,
pooled support account management, escalation management, and a minimum response time of less
than one hour.
• Premier. This is the highest level of support, and it extends to all Microsoft products, including Azure.
With Premier, you receive customer-specific advisory services, a dedicated support account manager,
cloud service dependency mapping, onsite services, and a response time of less than 15 minutes, in
addition to all of the features included with Professional Direct.
Additional Reading: For more information, refer to Azure Support For Customers:
http://aka.ms/N613e7.
Understanding other Azure resources

Microsoft provides several resources that you can
use to further manage and implement your Azure
environment:
• Azure Marketplace. The Azure Marketplace

contains thousands of certified, open source,
and community apps as well as developer
services that you can implement in Azure. You
can download preconfigured virtual
machines, developer tools, and a wide variety
of apps and APIs.
• VM Depot. The VM Depot offers community-
provided virtual machine images based on
open source operating systems that are configured for a wide variety of functionalities. Many VM
Depot images come preconfigured with a specific app, but images with other functionalities, such as
OpenVPN and database engines, are available as well.
• GitHub. GitHub contains APIs, SDKs, and open source projects uploaded and curated by the Azure
community. Developers can use GitHub resources in their Azure projects to save time and
development effort and upload their own code for reuse by other Azure users.
• Azure Trust Center. The Azure Trust Center provides information and guidance around security,
privacy, and compliance in Azure.
Demonstration: Working with Azure resources

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

Demonstration Steps
Use the Azure Marketplace

1. In Internet Explorer, navigate to the Azure Marketplace.
2. Search for Windows resources.
3. View the entry for the Windows Server 2012 R2 virtual machine.
4. On the Windows Server 2012 R2 Datacenter page, click Create Virtual Machine to start the virtual
machine creation process in Azure.
5. In Internet Explorer, sign in to the Azure portal, and then view the Windows Server 2012 R2
Datacenter blade.
6. In the Azure portal, click New, and then, next to Marketplace, click See all. View the available
options from the Azure Marketplace.
7. Search for and click the Windows Server 2012 R2 Datacenter virtual machine image. Note that the
Windows Server 2012 R2 Datacenter blade is the same as the one shown earlier in the demonstration.
Use the VM Depot

1. In Internet Explorer, go to http://vmdepot.msopentech.com.
2. View the available categories, and then filter the list by the Database and NoSQL category. Note the
filtered list of virtual machine images that appear. Also, note the options available for each virtual
machine image entry: Create Virtual Machine, Deployment Script, and Deployment Tutorial.
Use GitHub
1. In Internet Explorer, go to http://www.github.com/azure.
2. View the available repositories.
3. View the available templates under the azure-quickstart-templates repository.
Use the Azure Trust Center

• In Internet Explorer, go to http://azure.microsoft.com/support/trust-center to view the home
page for the Azure Trust Center.
Azure management tools

You can use several different tools to manage the
Azure environment. These include graphical
browser-based consoles, command shells, and
plug-ins. The following list explains the tools
available to you:
• Azure portals. You can use two browser-based

portal sites to manage your Azure
infrastructure:
o The Azure classic portal offers the original

Azure portal experience.
o The Azure portal, formerly known as the

Azure preview portal, is the default portal for Azure, and you can use it to administer Azure from
most web browsers.
• Windows PowerShell. You can use Windows PowerShell and the associated Azure modules to manage
your Azure environment.
• Azure Automation. The Azure Automation extension for Windows PowerShell Integrated Scripting
Environment (ISE) enables runbook creation for Azure PowerShell workflows from within the Windows
PowerShell ISE. You can use Azure Automation to create and test runbooks from your local computer.
• Azure CLI. The Azure command-line interface (CLI) provides a set of open source, cross-platform
commands for working with the Azure platform. The latest version of the Azure CLI is available from
GitHub and installable on the Windows and Linux platforms.
For example, an administrator can interrogate account information by typing azure account. The
Azure CLI can manage both resources and services. To configure resources, run the config mode
command azure config mode arm. To return to service management mode, run azure config mode
asm.
• Visual Studio. You can use Visual Studio to deploy resources in Azure by creating and applying Azure
Resource Manager templates. You can also use Visual Studio to create and publish websites. Doing so
involves the following high-level steps:
a. Set up the development environment. To use Visual Studio to publish your website content, you
must first install the Azure SDK. When you install the Azure SDK, it will automatically install Visual
Studio Express for Web.
b. Create your app. To create the app, launch Visual Studio, and then choose to create a new
project. You can then select the type of app that you want to use on your website—for example,
an ASP.NET web app. The subsequent options that you must configure vary, depending on the
type of app you initially selected.
c. Host in the cloud/Create remote resources. This option varies, depending on the edition of Visual
Studio. You can use this option to create the website during the publish process. It is enabled by
default. If you choose to create the website during publishing, you must define the site name,
region, and database options.
d. Deploy the app to Azure. After you create your app, you can publish it to Azure by using the
Publish Web Wizard. You must specify the server name and port, site name, user credentials to
authenticate with the website, and destination URL.
Check Your Knowledge

Question
Which of the following services is not provided by Azure?
Select the correct answer.
Virtual Machines
Web Apps
Storage Spaces
Azure Active Directory
Azure DNS
Lesson 3
Managing Azure with the Azure portal
Azure provides web-based portals in which you can provision and manage Azure subscriptions and
services. These portals usually provide the initial environment in which you work with Azure, and knowing
how to navigate and use them is a fundamental skill that IT professionals need to manage Azure services.
Lesson Objectives
• Explain the Azure classic portal.
• Explain the Azure portal.

• Describe how to manage account subscriptions with the Azure portal.
• Use the Azure portals to manage Azure.
Using the Azure classic portal

The Azure classic portal is the original user
interface for provisioning and managing Azure
services. It is implemented as a web app at
https://manage.windowsazure.com and requires
that you sign in by using a Microsoft account or
an organizational account that is associated with
one or more Azure subscriptions.
The Azure classic portal consists of a page for

each Azure service. The portal also includes an
All Items page, where you can view all the
provisioned services in your subscriptions, and
a Settings page, where you can configure
subscription-wide settings.
Provisioning services
You can provision a new instance of a service by clicking the New option on any page. Most services
provide a dialog box in which you can enter the user-definable settings for the service before creating it.
Service provisioning happens asynchronously, and an indicator is displayed at the bottom of the page to
show the current activity. You can expand this indicator to show a list of completed and in-process tasks.
Managing services
Your provisioned services are listed on the All Items page and on each service-specific page. The list
shows the name, status, and service-specific settings for each service. You can click a service name in the
list to view the dashboard for that service instance, where you can use multiple tabbed subpages to view
and configure the service-specific settings. In most cases, you make changes to a service by using the
dynamic toolbar of context-specific icons that displays at the bottom of the subpage.
Adding co-administrators
When you provision an Azure subscription, you automatically become the administrator for that
subscription, and you can manage all the services and settings for the subscription. You can add
co-administrators on the Settings tab of the Azure classic portal.
Using the Azure portal

The Azure portal, at https://portal.azure.com,
formerly known as the Azure preview portal, is
the new default portal for browser-based
administration in Azure. The new portal represents
a significant change in the way that you perform
administrative tasks in Azure.
Portal elements and concepts

The new portal contains the following user
interface elements:
• Dashboard. The home page for your Azure

environment. You can pin commonly used
items to the dashboard to make it easier to navigate to them. By default, the dashboard includes tiles
that show the global Azure service health, a shortcut to the Azure gallery of available services, and a
summary of billing information for your subscriptions.
• Blades. Panes in which you can view and configure the details of a selected item. Each blade displays
as a pane in the user interface, often containing a list of services or other items that you can click to
open other blades. New blades open to the right side. In this way, you can navigate through several
blades to view the details of a specific item in your Azure environment. You can maximize and
minimize some blades to optimize the screen space and simplify navigation.
• Hub menu. A bar on the left side of the page, which contains the following icons:
o Home. Returns the page to the left side so that the Hub menu and dashboard are visible.
o Notifications. Opens a blade on which you can view notifications about the status of tasks.
o Browse. Starts a journey to view the details of a service in your Azure environment.
o Billing. Provides details about charges and the remaining credit for your subscriptions. Billing is
also available on a resource group basis.
o New. Creates a new service in your Azure environment.
Managing account subscriptions with the Azure portal

To manage your Azure subscriptions, you can sign
in to the Azure portal. From here, you can view
and edit your subscription, including usage
statistics and billing details. You can also edit your
profile. You can open the subscriptions page
from the full portal by clicking your account name
and then clicking View my bill.
The following options are available on the

subscriptions page:
• Change payment method
• Download usage details

• Contact Microsoft support
• Edit subscription details

• Change subscription address
• View partner information
• Cancel your subscription
On the subscriptions page, you can also enable preview features in your subscriptions. Preview features
are Azure services that have not been fully released but that have been made available for testing and
evaluation.
Additional Reading: For more information, refer to Sign in to Azure: http://aka.ms/J1breg.
Note: If you have an Enterprise Agreement with Microsoft, you can also manage Azure
accounts and usage data for all the accounts in your organization by using the Azure Enterprise
Portal.
Additional Reading: For more information, refer to ea.microsoftazure.com:

http://aka.ms/V91c9h.
Demonstration: Using the Azure portals

• Use the Azure classic portal.

• Use the new Azure portal.
• Manage Azure subscriptions.
Demonstration Steps
Use the Azure classic portal
1. In Internet Explorer, browse to http://manage.windowsazure.com, and then sign in by using the
Microsoft account that is associated with your Azure subscription.
2. Navigate to Settings and then Subscriptions. View the Administrator accounts.
3. Create a new storage account.
4. After the storage account is created, view the configuration settings of the storage account.
5. View All Items and ensure that the new storage account is displayed.
Use the Azure portal

1. At the top of the Azure classic portal, click Check out the new portal, and then click Launch. A new
tab opens in Internet Explorer.
2. View the tiles on the Dashboard page of the new portal.
3. View the Service Health page.
4. Browse to the Storage account (classic) resource to show the storage account created in the Azure
classic portal.
5. View the details of the storage account, and then pin it to the dashboard.
6. Create a new web app in the Demo-Web-App resource group, and then add it to the Dashboard.
7. Switch to the tab containing the Azure classic portal, and then refresh the page.
Note: The website you created in the Azure portal is listed on the ALL ITEMS page.
Manage Azure subscriptions

1. In the upper right of the Azure classic portal, click your Microsoft account name, and then click View
my bill. A new tab opens in Internet Explorer. If prompted, sign in by using the Microsoft account
credentials associated with your Azure subscription.
2. On the subscriptions page, click your subscription. Then review the summary of usage and billing
that displays.
3. Close Internet Explorer, closing all tabs if prompted.
Question: What are some of the advantages of the Azure portal as compared to the Azure
classic portal?
Lesson 4
Managing Azure with Windows PowerShell
The Azure portals provide a graphical user interface (GUI) for managing Azure subscriptions and services,
and in many cases, they are the primary management tools for service provisioning and operations.
However, it is common to want to automate tasks by creating reusable scripts or to combine the
management of Azure resources with the management of other network and infrastructure services.
Windows PowerShell provides a scripting platform for managing Windows and can be extended to a wide
range of other infrastructure elements, including Azure, by importing modules of encapsulated code,
called cmdlets. This lesson explores how you can use Windows PowerShell to connect to an Azure
subscription and to provision and manage Azure services.
Lesson Objectives
• Identify the Azure modules for Windows PowerShell.
• Explain the differences between Azure AD Authentication and certificate authentication.
• Identify the Windows PowerShell cmdlets used for the classic deployment model and for Azure
Resource Manager.
• Use Windows PowerShell to manage Azure.
Azure PowerShell modules

You can implement several modules for Windows
PowerShell to enable the administration of Azure
by using Windows PowerShell.
Azure PowerShell
Azure PowerShell includes the following modules:
• Azure. A core set of cmdlets for managing
Azure services.
• AzureRM. A set of cmdlets for managing

resource groups.
• AzureProfile. A set of cmdlets for managing

authentication and execution context.
The Azure PowerShell module has a dependency on the Microsoft .NET Framework 4.5 and the Web
Platform Installer (Web PI) checks for this during installation.
You must install Azure PowerShell on a computer before you can use the Azure PowerShell cmdlets. You
can install Azure PowerShell in several ways, including:
• Web PI. You can launch the Web PI from https://azure.microsoft.com/en-us/downloads/.
• PowerShell Gallery. You can import the Azure PowerShell modules from PowerShell Gallery by
running the following cmdlets directly from a PowerShell prompt:
Install-Module AzureRM
Install-Module Azure
Import-AzureRM
Import-Module Azure
These cmdlets download the modules and install them into Windows PowerShell, provided your
computer is connected to the Internet and you are running Windows PowerShell as an Administrator.
Note: This functionality requires Windows Management Framework (WMF) 5.0

or PackageManagement PowerShell modules. At the time of writing this content, the
PackageManagement PowerShell modules are in preview.
Azure AD module for Windows PowerShell

If you plan to implement Azure AD, you can install the Azure AD module for Windows PowerShell to
manage users, groups, and other aspects of the directory from Windows PowerShell. This module requires
the Microsoft Online Services Sign-In Assistant to be installed.
Additional Reading: For more information, refer to AzureADHelp: http://aka.ms/X4nin4.
Azure Automation authoring toolkit

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

Install-AzureAutomationIseAddOn
Authenticating to Azure by using Windows PowerShell

After you install the Azure PowerShell module,
you need to connect it to the Azure subscriptions
that you want to manage with it. You can take
two approaches to accomplish this: Azure AD
Authentication and certificate-based
authentication.
Azure AD Authentication
You can use Azure AD Authentication to sign in to an Azure account by using one of the following
credentials:
• A Microsoft account that is associated with an Azure subscription
• An organizational account that is defined in Azure AD
To connect an Azure account to the local Windows PowerShell environment, you can use the Login-
AzureRmAccount cmdlet. This opens a browser window in which the user can interactively sign in to
Azure by entering a valid user name and password.
Azure AD Authentication is token based, and after signing in, the user remains authenticated until the
authentication token expires. The expiration time for an Azure AD token is 12 hours, although you can
refresh it in the Windows PowerShell session.
After you authenticate, you can use the Get-AzureRmContext cmdlet to view a list of the Azure accounts
and subscriptions that you have associated with the local Windows PowerShell environment. Similarly, you
can use the Get-AzureRmSubscription cmdlet if you want to view a list of subscriptions. If you have
multiple subscriptions, you can set the current subscription by using the Set-AzureRmContext cmdlet
with the name or ID of the subscription that you want to use.
Certificate-based authentication
Most tools for managing Azure support Azure AD Authentication, and it is the recommended
authentication model. However, in some cases, it might be more appropriate to authenticate by using
certificates. Examples of where certificate-based authentication is appropriate include older tools that do
not support Azure AD Authentication and Windows PowerShell scripts that will run for long periods of
time in which an authentication token might expire.
Specifics of implementing certificate-based authentication depend on whether you intend to execute

Azure Service Management or Azure Resource Manager cmdlets. Azure Service Management cmdlets
support the use of management certificates. Once you generate such a certificate, you need to store its
private key in the local certificate store and upload the corresponding public key into the target
subscription. With Azure Resource Manager, the process involves creating an Azure AD application and a
corresponding service principal. During this step, you have the option of associating the application
instance with a certificate by uploading its public key.
Additional Reading: For more information, refer to Authenticating a service principal with
Azure Resource Manager: http://aka.ms/Yym3a7.
Using an Azure-generated certificate in Azure Service Management

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

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

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

$subName = "<the subscription name">
$subID = "<copy the subscription ID from the Azure portal>"
$thumbprint = "<the thumbprint of the certificate you want to use>"
$cert = Get-Item cert:\\currentuser\my\$thumbprint
Set-AzureSubscription -SubscriptionName $subName, -SubscriptionId $subId -Certificate
$cert
To obtain the certificate thumbprint, you can either view the certificate in Certificate Manager or use the
Windows PowerShell command Get-Item cert:\\currentuser\my\* to obtain a list of all the personal
certificates and their thumbprints.
Azure PowerShell cmdlets for the classic deployment model and for Azure
Resource Manager
After you connect your Windows PowerShell
environment to your Azure subscription, you can
use Azure PowerShell cmdlets to view, provision,
and manage Azure services. You can use two
different deployment models: classic and Azure
Resource Manager. The classic deployment model
uses the Azure module for PowerShell, whereas
the Azure Resource Manager model uses the
AzureRM module for PowerShell.
The primary difference between the cmdlets in the two modules is the inclusion of the letters Rm in the
Azure Resource Manager module cmdlets. For example, the New-AzureVM cmdlet in the Azure module
is replaced by NewAzureRmVM in the Azure Resource Manager module. The following table illustrates
further differences between the two models.
Functionality or command Classic Azure Resource Manager
PowerShell module used Import-Module Azure Import-Module AzureRm
Create a resource group New_AzureResourceGroup New-AzureRmResourceGroup
Create a virtual machine New-AzureVM New-AzureRmVM
Create a web app New-AzureWebsite New-AzureRmWebapp
Sign-in to Azure Add-AzureAccount Login-AzureRmAccount
GUI Element Classic portal Azure portal
Manage resources created No Yes

in other model
Demonstration: Using Azure PowerShell

• Create a resource group.
• Create a storage account.
• Configure a storage account.

• Delete a storage account.
• Delete a resource group.
Demonstration Steps
Create a resource group

1. Open the Windows PowerShell ISE.
2. In the Windows PowerShell ISE, open D:\Demofiles\Mod01\UsingAzurePowerShell.ps1.
3. In the Windows PowerShell ISE, at the command prompt, type the following command, and then
press Enter:
Login-AzureRmAccount
4. Enter your Azure credentials.
5. In the Windows PowerShell ISE, change the $saName variable on line 8 to a value that will be unique
in Azure.
6. In the Windows PowerShell ISE, change the $locName variable to the Azure region you will be using
throughout the course, as provided by your instructor.
7. In the Windows PowerShell ISE, select the following lines, right-click them, and then click Run
Selection:
$locName = "East US"

$rgName = "TestRG1"
$saName = "<enter unique name here>"
$saType = "Standard_LRS"
$newsaType = "Standard_GRS"
Selection:
New-AzureRmResourceGroup -Name $rgName -Location $locName
Create and configure a storage account

Selection:
New-AzureRmStorageAccount -Name $saName -ResourceGroupName $rgName –Type $saType

-Location $locName
Selection:
Set-AzureRmStorageAccount -Name $saName -ResourceGroupName $rgName –Type $newsaType
Delete a storage account

Selection:
Remove-AzureRmStorageAccount -Name $saName -ResourceGroupName $rgName
Selection:
Get-AzureRmStorageAccount
Delete a resource group

Selection:
Remove-AzureRmResourceGroup -Name $rgName
2. In the Confirm selection window, click Yes.
Selection:
Get-AzureRmResourceGroup
Reset the environment

1. In the Windows PowerShell ISE, type the following command, and then press Enter:
Reset-Azure
2. When prompted (twice), sign in by using the Microsoft account associated with your Azure
subscription.
3. If you have multiple Azure subscriptions, select the one you want the script to target.
4. When prompted for confirmation, type y.
5. Wait for the script to complete, and then close all open windows.
Question: How can you differentiate between classic model cmdlets and Azure Resource
Manager cmdlets?
Lesson 5
Overview of Azure Resource Manager
With Azure Resource Manager, you can administer your Azure resources as a logical group. You can
perform administrative tasks such as deploying, updating, and deleting resources for a solution or similar
group of resources in a single, coordinated operation. This lesson introduces you to the core components
and functionality of Azure Resource Manager and explains methodologies and best practices.
Lesson Objectives
• Describe Azure Resource Manager.
• Explain resources and resource groups.
• Describe the Azure Resource Manager deployment methodologies.
• Explain the implementation guidelines for IaaS v2.
What is Azure Resource Manager?

Azure Resource Manager introduces a logical
approach to managing Azure resources. Azure
service instances, or resources, can be logically
stored in resource groups. Resource groups
provide a common management point for the
resources belonging to the group. They can be
created, managed, monitored, or deleted
together. Azure Resource Manager also offers the
concept of deployment templates. This allows you
to define a collection of resources in the form of a
template and then use this template to deploy
these resources into a resource group.
Resource groups and deployment templates are ideal for scenarios where you need to quickly build out
development, test, quality assurance, or production environments. Developers can quickly delete their
environment by removing a resource group and create a new environment by redeploying a template.
The resource groups can be monitored to determine the billing rate or resource usage at a higher level
than that of monitoring individual resources.
Azure Resource Manager vs. classic deployment mode

In classic deployment mode (formerly known as Azure Service Management), services are created in the
Azure classic portal or through the Service Management Azure PowerShell cmdlets. In this case,
configuration of virtual machines is determined by:
• A mandatory cloud service that serves as a logical container for virtual machines.
• A mandatory storage account that hosts the virtual machines’ operating systems and data disk .vhd
files.
• An optional virtual network that allows you to implement direct connectivity among virtual machines
in different cloud services and on-premises networks.
To create resources through Azure Resource Manager, you use the new portal or the Azure Resource
Manager cmdlets in Azure PowerShell. The resources carry the following characteristics:
• A virtual machine depends on a storage account defined by the storage resource provider to store its
.vhd files in BLOB storage.
• A virtual machine references a specific network adapter defined by the network resource provider.
• The network adapter determines the virtual machine’s private IP address, referencing the subnet of
the virtual network, and an optional network security group.
The following resource providers differentiate between resources created using the classic deployment
mode versus those created by Azure Resource Manager:
• Compute
• Storage
• Network
For these resources, the supported operations differ between the management modes.
Using templates and tags

You can use templates and tags to further streamline your management of resource groups with Azure
Resource Manager:
• Templates provision all of the resources for your solution in a single, managed operation. In the
template, you dictate the resources that the solution needs and set deployment parameters to
provide values for different environments. When you create a template, you need to know:
o Which types of resources you need to deploy.

o Where resources will be stored.
o What the order is for the deployment of resources.
o How and when you will pass values to the deployment, and what those values will be.
• You can create tags in templates or in the portal to logically organize resources. Tags are key/value
pairs that you define to properly identify resource properties. You can use tags to view or manage
resources according to the tags assigned to them.
Advantages of Azure Resource Manager

Azure Resource Manager carries several advantages over the classic deployment mode:
• Manage resources as a group, rather than individually.

• Reuse solutions and consistently deploy resources.
• Create templates to quickly deploy and redeploy large solutions.
• Define dependencies and resource deployment order.
• Use role-based access control (RBAC) to apply access control to a group of resources.
• Logically organize resources by using tags.

Resources and resource groups

Every Azure resource belongs to a resource group.
You can choose to create a new resource group or
to use an existing resource group when creating a
resource.
When you deploy a solution that consists of a few

resources working together, you should create a
dedicated resource group so that you can manage
the life cycle of all the related assets by using this
resource group. You can add or remove additional
resources from the resource group as your app
evolves. For example, the Website + SQL option
in the Azure portal creates a new resource group
that consists of a website, a web hosting plan, and an Azure SQL database, along with other resources.
You can view resource groups either by using the new portal or Azure PowerShell. By using the Azure
portal, you can view and monitor resource groups as a group. The portal displays each resource group as
a blade, providing you with the information about its characteristics.
Adding resources
You can add resources to a resource group at any time. The Azure portal has an Add option that you can
use to add a new resource to a resource group. Resource groups also enable you to manage the life cycle
of all the contained resources. Deleting a resource group will delete all the resources contained within it.
The Azure Resource Manager mode in Azure PowerShell allows you to manage resource groups in your
Azure subscription. You can create resource groups by using the New-AzureRmResourceGroup cmdlet.
You can then use the New-AzureRmResource cmdlet to manually create resources and add them to the
resource group. You can also use a deployment template to add resources to a resource group.
Moving resources
You can move resources between resource groups, and you might do so for several reasons:
• A resource needs to be located in a different logical grouping or Azure subscription.
• A resource does not share the same life cycle with other resources that were in its group.
It is important to consider the following factors when moving a resource:
• You cannot change a resource’s location. After you create a resource, it must remain in the same
datacenter.
• You should group resources only with other resources that share the same life cycle.
• You should use the latest version of the Azure PowerShell module if you are using it to move
resources.
• Both the source and destination resource groups are blocked for deletion while the move operation
takes place.
• The ability to move resources is limited to specific resource types only.
Additional Reading: For more information, refer to Move resources to new resource group
or subscription: http://aka.ms/Ry0sqz.
Azure Resource Manager deployment methodologies

With Azure Resource Manager, the template
you create defines the infrastructure for your
solution, how to configure that infrastructure, and
how to implement the solution on top of that
infrastructure. Azure Resource Manager analyzes
dependencies to help ensure that resources are
created in the correct order before allowing
resources to be deployed.
When creating templates, you should divide your

deployment components into a set of targeted,
purpose-specific templates. You can easily reuse
these templates for different solutions. To deploy
a particular solution, you create a master template that links all of the required templates.
You can also use the template for updates to the infrastructure. For example, you can add a new resource
to your solution. You can also delete resources that exist in your solution by excluding them from the
template before its deployment.
You can specify parameters in your template to allow for customization and flexibility in deployment. For
example, you can pass parameter values that tailor the deployment for your test environment. By
specifying different parameters, you can use the same template for a deployment to the production
environment.
Azure Resource Manager provides extensions for scenarios when you need to configure operating systems
within Azure virtual machines. These extensions include a number of configuration management services,
such as Desired State Configuration, Chef, or Puppet.
When you create a solution from the Azure Marketplace, the solution automatically includes a
deployment template. You do not have to create your template from scratch, because you can start with
the template for your solution and customize it to meet your specific needs.
Finally, templates support versioning. You can check them in to your source code repository and update
them as your app evolves. You can edit the template through Visual Studio.
Best practices
Some of the best practices for deploying solutions by using templates include:
• Use a consistent deployment method.
• Use resource groups to group all resources in a solution together.
• Use RBAC to grant access to resources.
• Define and deploy your infrastructure through the declarative syntax in Azure Resource Manager
templates rather than through imperative commands.
• Define all the deployment and configuration steps in the template. You should have no manual steps
for setting up your solution.
• Run imperative commands to manage your resources, such as to start or stop an app or virtual
machine.
• Arrange resources with the same life cycle in a resource group. Use tags for all other organization of
resources.
Azure IaaS v2 implementation guidelines

There are certain guidelines to consider when
implementing IaaS solutions by using Azure as
listed under the following headings.
General naming conventions

You should establish a consistent naming
convention for all the resources you create within
Azure. Consider the following:
• Ensure that names are consistent across the

entire organization and across Azure
subscriptions.
• Identify Azure resources by using either a

prefix or a suffix for the resource. For example, you can use RG-OrdersApp or OrdersApp-RG to
denote a resource group named OrdersApp.
• Use a consistent format when indicating dates.
• Ensure that virtual machines have the same name as the host name of the operating system instance
within the virtual machine.
• Ensure that storage account names use only lowercase letters and numbers and are globally valid and
unique.
• Some services might require or prohibit the use of certain character types, such as lowercase,
uppercase, or symbols.
Storage
Consider the following when working with storage:
• Use multiple storage accounts to increase the I/O capability.
• Name the underlying disks and BLOBs logically, according to use.
Virtual networks
Consider the following when working with virtual networks:
• Plan IP addressing in subnets. Azure uses five IP addresses in each network of a subnet.
Virtual machines
Consider the following when working with virtual machines:
• Azure, by default, assigns the computer name as the name of the associated cloud service when
creating a virtual machine in the Azure classic portal.
Question: If you are creating an IaaS infrastructure using the Azure Resource Manager
model, which management tools can you use?
Lesson 6
Azure management services
You can manage and monitor your Azure environment by using both the built-in tools in Azure and
external tools, such as System Center. This lesson outlines the primary management services and methods
available for Azure and explains how you can use them in your environment.
Lesson Objectives
• Describe the Microsoft Operations Management Suite (OMS).
• Explain how to run logging and diagnostics in Azure.

• Explain how to manage accounts, subscriptions, and administrative roles in Azure.
OMS
OMS extends an organization’s existing System
Center deployment into the cloud, providing
enterprise-wide infrastructure management from
a single console. OMS enhances the following
operational aspects when you administer your
Azure environment:
• Operational visibility and management:
o Proactive smart alerts
o Operations dashboard and reporting

o Real-time, customizable reporting
• Security:
o Security log collection
o Breach and threat detection
o Forensic analysis
• Performance monitoring and analytics:

o Resource monitoring for Windows and Linux
o On-premises server performance monitoring
o Azure server performance monitoring
o Storage area network (SAN) storage analytics
• Log management:
o Universal log collection and analysis

o Virtually unlimited data retention
o A dashboard powered by search queries

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

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

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

You can use several different methods to monitor
Azure:
• Logs. All Azure services provide operations

logs to record operational information as it
relates to Azure management. You can access
operations logs via the GUI in two ways:
o From the dashboard of the job or service

in the Azure portal
o From Management Services in the

Azure classic portal
Logs contain the events that have impacted any of your subscriptions and provide the following
information:
o The level of the event. For example, it might be just something to track (Informational) or
something that has gone wrong that you need to know about (Error).
o The status. The final status is generally Succeeded or Failed, but it might be Accepted for long-
running operations.
o When the event occurred.
o The user or service that performed the corresponding operation.

o The Correlation ID of the event. This is the unique identifier of the corresponding operation.
You can filter audit log events by subscription, resource group, resource type, or specific resource.
You can access the audit logs from the Azure portal under Audit logs.
• Azure Diagnostics. Azure Diagnostics allows you to collect diagnostic telemetry data from services
running in Azure. The telemetry data is stored in an Azure storage account and can be used for
debugging and troubleshooting, measuring performance, monitoring resource usage, analyzing
traffic and capacity planning, and auditing.
In case of virtual machines, Azure Diagnostics collects a superset of telemetry data, including:
o Microsoft Internet Information Services (IIS) logs. Information about IIS websites.
o Azure Diagnostics infrastructure logs. Information about Azure Diagnostics.
o IIS failed request logs. Information about failed requests to an IIS site or app.
o Windows event logs. Information sent to the Windows event logging system.
o Performance counters. Operating system and custom performance counters.
o Crash dumps. Information about the state of the process in the event of an app crash.
o Custom error logs. Logs created by your app or service.

o .NET EventSource logs. Events generated by your code by using the .NET EventSource class.
Azure access management

Your Azure subscription is related to your Azure
account and administrative roles. It is important to
understand the differences among accounts,
subscriptions, and administrative roles in Azure so
that you can effectively manage your Azure
environment.
Accounts and subscriptions

An Azure account determines how and to whom
your Azure usage is reported. A subscription helps
you to organize your access to your cloud services
and resources, and also to control how your
resource usage is reported, billed, and paid for.
Each of your subscriptions can have a different billing and payment setup. As a result, you can have
different subscriptions and different plans by department, project, regional office, or other factor. Every
cloud service belongs to a subscription, and the subscription ID is often required for some operations.
Administrative roles
Three Azure administrative roles exist:
• Account administrator. Each Azure account has one account administrator. The account administrator
has the authority to access the Azure Account Center, in which he or she can create subscriptions,
cancel subscriptions, change the billing for a subscription, and change service administrators, among
other tasks.
• Service administrator. Each Azure subscription has one service administrator. The service
administrator can access all resources in the subscription. By default, the user account associated with
this role is the same as that of the account administrator when your subscription is created.
• Co-administrator. This role has the same functions as the service administrator, but it cannot change
the association of subscriptions with an Azure AD tenant.
Note: The account administrator for a subscription is the only person who has access to the
Azure Account Center. Account administrators do not have any other access to services in that
subscription.
The following table summarizes the differences among the three Azure administrative roles.
Administrative role Limit Summary
Account administrator One per Azure account Authorized to access the Azure
Account Center (create subscriptions,
cancel subscriptions, change the
billing for a subscription, change
service administrators, and more).
Service administrator One per Azure subscription Authorized to access the Azure portal
for all the resources in the
subscription. By default, same as the
account administrator when a
subscription is created.
Co-administrator Unlimited Authorized with the same access as

the service administrator, but this role
cannot change the association of
subscriptions with an Azure AD
tenant.
RBAC
Azure supports RBAC for granular access management. By using RBAC, you can separate duties within
your teams and grant users only the level of access that they require to perform their jobs.
Azure RBAC has three basic roles that can apply to all resource types:
• Owner. Has full access to all resources, including the right to delegate access to others.
• Contributor. Can create and manage all Azure resource types but cannot grant access to them.
• Reader. Can view existing Azure resources.
The rest of the RBAC roles in Azure allow the management of specific Azure resources. For instance, the
Virtual Machine Contributor role allows the creation and management of virtual machines but does not
permit the management of the virtual network or the subnet that the virtual machine is connected to.
You can also create your own roles for RBAC, and define access for the roles according to your needs.
Note: RBAC role assignment is available when using the Azure portal. Azure RBAC allows
you to grant appropriate access to Azure AD users, groups, and services by assigning roles to
them on a subscription, resource group, or individual resource level. The assigned role defines the
level of access that the users, groups, or services have to the Azure resource.
Additional Reading: For more information, refer to Azure Role-Based Access Control:
http://aka.ms/Uwlokh.
Question: Which built-in role holds the greatest scope of administrative privilege in Azure?
Lab: Managing Microsoft Azure

Scenario
A. Datum Corporation wants to expand their cloud presence by taking advantage of the benefits of Azure.
You have been asked to explore and compare the available IaaS v2 features by using the Azure portals
and Windows PowerShell.
Objectives
After completing this lab, you will be able to:
• Use the Azure portals.
• Use Azure Resource Manager features via the Azure portal.
• Use Azure PowerShell.
Lab Setup
Estimated Time: 50 minutes
Virtual machine: 20533C-MIA-CL1

User name: Student
Password: Pa$$w0rd
Before you start this lab, ensure that you have completed the tasks in the “Preparing the environment”
demonstration, which is in the first lesson of this module. Also ensure that the setup script has completed.
Exercise 1: Using the Azure portals

Scenario
You have been asked to explore the available browser-based Azure portals to assess how A. Datum
Corporation will use them. In the Azure classic portal, you must create a co-administrator account and
confirm the domain name of your subscription for use in your testing.
In the Azure portal, you must observe the organization of resources and customize the interface to make
your testing environment more accessible. In the account page of the Azure portal, you must view and
download your current billing data and sign up for an available preview feature that you will use later in
your testing.
The main tasks for this exercise are as follows:

1. Use the Azure classic portal.
2. Use the Azure portal.
3. Use the account page of the Azure portal.
 Task 1: Use the Azure classic portal

1. Ensure that you are signed in to the 20533C-MIA-CL1 virtual machine as Student with the password
Pa$$w0rd. You should have already run the preparation script in the “Preparing the environment”
demonstration at the beginning of the module.
2. Open Internet Explorer, and then go to https://manage.windowsazure.com.
3. Sign in by using the email address and password you set up for this course.
4. Open the settings page and then the ADMINISTRATORS page.

5. Add a co-administrator account by using a random, unique email address ending with
@outlook.com.
6. In Internet Explorer, navigate to the ACTIVE DIRECTORY page in the Azure classic portal. If the Let’s
talk about Azure AD page appears, clear all check boxes, and then click the check mark at the
bottom of the page.
7. On the Domains page, note the domain name for your subscription.
8. On the Users page, note the two users: your user account and the co-administrator account you
created earlier.
 Task 2: Use the Azure portal

1. Go to the Azure portal at https://portal.azure.com.
2. Click the Edit dashboard option to edit the layout of the Dashboard page.
3. Resize the All resources tile to 4x6.

4. Resize the Service health tile to 2x4.
5. Click Done customizing to confirm the changes to the Dashboard page.
6. On the Hub menu, use the Browse menu to pin the Storage accounts item to the Hub menu.
 Task 3: Use the account page of the Azure portal

1. In Internet Explorer, go to the account page of the Azure portal at
https://account.windowsazure.com.
2. Sign in by using the email address and password you set up for this course.
3. Go to the Subscriptions page, and then click your subscription. View the billing summary for your
subscription on the page.
4. Click Download usage details, download the version 1 usage details for your subscription, and then
view them in Notepad. Note that this is intended to simply review its content – typically to analyze it
in more details, you would use Microsoft Excel or other program capable of parsing .csv files.
Results: After completing this exercise, you will have used the Azure portals.
Exercise 2: Using the Azure Resource Manager features in the Azure portal
Scenario
You have been asked to create some temporary resources in Azure to test the management interface of
the Azure portal. You must create a resource group in Azure, create a new storage account and a new
virtual machine in the Azure portal, and then tag the resources as test resources before assigning your
newly added co-administrator to the Automation Operator role in the Azure portal.
1. Create and manage a resource group.
2. Create Azure resources.
3. Configure tagging.
4. Configure RBAC.
 Task 1: Create and manage a resource group

1. In Internet Explorer, go to https://portal.azure.com.
2. In the Azure portal, create a new resource group named TestRG1 in your preferred location.
 Task 2: Create Azure resources

• On the Azure portal page, create a new IaaS v2 storage account assigned to the TestRG1 resource
group. Use the current date and your initials to create a unique name in the format
storageMMDDYYYYab format.
Note: For example, a student named Ed Meadows might use storage04252016em.

All alphabetical characters must be lowercase.
 Task 3: Configure tagging

1. In the Azure portal, open the TestRG1 resource group pane.
2. Create a tag named project:Test, and then assign it to the TestRG1 resource group.
3. Assign the project:Test tag to the storageDDMMYYYYab storage account, and then pin the
project:Test tag to the dashboard.
4. On the Dashboard page, view the resources that are tagged with the project:Test tag.
 Task 4: Configure RBAC

• From the Dashboard page, add the user you created earlier in this lab as a Storage Account
Contributor for the TestRG1 resource group.
Results: After completing this exercise, you will have used the Azure Resource Manager features in the
Azure portal.
Exercise 3: Using Azure PowerShell

Scenario
You have been asked to investigate the capabilities of Azure PowerShell for A. Datum Corporation. You
must connect to your Azure subscription by using Azure PowerShell and then use Azure PowerShell to
create an IaaS v2 web app, create a new resource group named TestWebRG, and reassign the web app to
the new resource group.
1. Connect Azure PowerShell to your Azure subscription.

2. Manage Azure services and resource groups.
3. Reset the environment.

 Task 1: Connect Azure PowerShell to your Azure subscription

1. On MIA-CL1, on the taskbar, click Start, type ISE, and then click Windows PowerShell ISE.
press Enter:
Login-AzureRMAccount
3. In the sign-in window that appears, sign in to your Azure account.
4. In the Windows PowerShell ISE window, at the command prompt, type the following cmdlet, and
then press Enter:
Get-AzureRmSubscription
then press Enter:
Get-AzureRmResourceProvider
6. View the Azure resource providers, resource types, and the Azure regions where these resources are
available.
 Task 2: Manage Azure services and resource groups

1. In the Windows PowerShell ISE window, open the D:\Labfiles\Lab01\Starter\Lab01Starter.ps1 file.
2. In the ISE, in the #Variables section, modify the $locName variable to match the Azure location that
your instructor asked you to use.
3. In the ISE, in the #Variables section, modify the $webappName variable to a unique name by using
the current date and your initials in the TestWebAppMMDDYYAB format.
4. In the ISE, under the line that starts: #Create a web app, use the New-AzureRmWebApp cmdlet to
create a new web app, using the variables in the script.
5. Type the following command, and then press Enter to view the resources in the TestRG1 resource
group:
Get-AzureRmResource | Where {$_.ResourceGroupName -eq $rgName}
6. At the PowerShell prompt, create a new resource group for the web app by using the $newrgname
and $locname variables.
7. In the Windows PowerShell ISE window, in the script pane, under the line that starts with #Move the
web app, create a variable named $resource, and assign the results of the following cmdlet to the
variable by typing the following code and pressing Enter:
Get-AzureVMResource –ResourceName $webappName –ResourceGroupName $rgName
8. In the Windows PowerShell ISE window, under the line you just created, use the Move-
AzureRmResource cmdlet to move the web app in the $resource variable to the resource group
contained in the $newrgname variable. You need to use the ResourceID parameter with the value of
$resource.ResourceID for the cmdlet to run successfully.
9. Select the code you created in steps 7 and 8, and then run the selection.
10. Run the following command to view the resources in the TestWebRG resource group:
Get-AzureRmResource | Where {$_.ResourceGroupName -eq $newrgName}

 Task 3: Reset the environment

1. Launch Windows PowerShell as an administrator.
2. From the Windows PowerShell prompt, run the following command:
Reset-Azure
subscription.
Note: This script removes Azure services in your subscription. Therefore, we recommend
that you use an Azure trial pass that was provisioned specifically for this course and not your own
Azure account.
The script resets your Azure environment so that it is ready for the next lab.
The script removes all storage accounts, virtual machines, virtual networks, cloud services, and
resource groups containing these resources.
Results: After completing this exercise, you will have used Azure PowerShell to create and manage Azure
resources.
Question: Why did you use Azure PowerShell cmdlets that contained Rm in the lab?
Module Review and Takeaways

Real-world Issues and Scenarios
• You can use the Azure module for Windows PowerShell to create simple and easy-to-use provisioning
scripts that enable you to create complex cloud-based solutions and infrastructure components on
demand.
Tools
The following table lists the tools that this module references:
Tool Use to Where to find it
The Azure portal Manage Azure

Additional Reading: For more
information, refer to the Azure portal:
https://portal.azure.com.
The Azure classic Manage Azure
portal Additional Reading: For more
information, refer to Microsoft Azure:
https://manage.windowsazure.com.
The Azure Manage multiple Azure
Enterprise portal subscriptions under an Additional Reading: For more
Enterprise Agreement information, refer to ea.microsoftazure.com:
http://aka.ms/V91c9h.
Azure modules for Manage Azure from Install by using the Microsoft Web Deployment
PowerShell PowerShell Tool (Web Deploy) or from the PowerShell
Gallery.
2-1
Module 2
Implementing and managing Azure networking
Contents:
Module Overview 2-1
Lesson 1: Overview of Azure networking 2-2
Lesson 2: Implementing and managing virtual networks 2-17
Lab A: Using a deployment template and Azure PowerShell to implement

Azure virtual networks 2-25
Lesson 3: Configuring Azure virtual network 2-29

Lesson 4: Configuring virtual network connectivity 2-39
Lesson 5: Overview of Azure networking in IaaS v1 2-50
Lab B: Configuring connectivity between IaaS v1 and IaaS v2 2-58

Module Overview
Networking is one of the primary building blocks of Microsoft Azure (Azure). Therefore, having a clear
understanding of how to configure network components and connect them together is essential. In this
module, you will learn how virtual networking provides the glue that brings together virtual machines
(VMs), web apps, and storage to enable you to publish a service onto the Internet.
Objectives
• Plan virtual networks in Azure.
• Implement and manage virtual networks.
• Configure intersite connectivity with virtual networks in Azure.
• Configure networking components.
• Plan virtual networks in infrastructure as a service (IaaS) version 1 (v1).

2-2 Implementing and managing Azure networking
Lesson 1
Overview of Azure networking
Similar to on-premises networks, you need to plan Microsoft Azure networks carefully to ensure that they
work as expected. Knowing how to plan on-premises networks translates relatively simply into the Azure
environment. You can use similar principals for designing an IP addressing scheme, when you configure
name resolutions, and when you want to achieve load-balanced and highly available solutions.
Lesson Objectives
• Describe the overall functioning of virtual networking in Microsoft Azure.
• List the features that Azure virtual networks support.
• Explain network interface cards (NICs), and describe how to configure IP addresses.
• Explain how to design IP address space and subnet allocation to manage host numbers.
• Explain functionality of Azure Load Balancer.
• Explain how to plan for effective name resolution in Azure virtual networks.
Demonstration: Preparing the Azure environment

Perform the following tasks to prepare the lab environment. The Azure services that you will use in the
labs will be described in this module while the environment is being configured.
Important: The scripts that you use in this course could delete any objects that you have in
your subscription. For this reason, you should complete this course by using a new Azure
subscription. You should have received sign-up details and instructions for creating an Azure
Learning Pass for this reason. Alternatively, create a new Azure Trial Subscription. In both cases,
use a new Microsoft account that has not been associated with any other Azure subscription. This
eliminates the possibility of confusion during labs and when running setup scripts.
The labs in this course use custom Microsoft Azure PowerShell cmdlets, including Setup-Azure to prepare
the Azure environment for a lab, and Reset-Azure to perform clean-up tasks at the end of a lab. For this
lab, Setup-Azure removes references to Azure subscriptions and accounts from the Azure PowerShell
session.
Before you start the lab preparation, your Instructor will decide which Azure region is the closest to your
classroom location, and which Azure region is second closest. You will need this information during the
demos and the labs.
Demonstration Steps
Sign in to Your Azure Subscription

1. Ensure that the MSL-TMG1 and 20533C-MIA-CL1 virtual machines are both running, and then sign in
to MIA-CL1 as Student with the password Pa$$w0rd.
2. Sign in to the Azure portal by using the Microsoft account that is either the Service Admin or
co-admin of your Azure subscription.
3. Close any initial "Welcome" messages in the portal.

Prepare the Azure Environment

Account Control dialog, click Yes.
Setup-Azure
3. At the command prompt, type the module number, and then press Enter.
5. When prompted, sign in to your Azure subscription by using an account that is either its Service
Administrator or a Co-administrator.
6. If you have multiple Azure subscriptions, select the one you want to use for this module.
7. When prompted, provide the number corresponding to the Azure region that the Instructor provided
as the second closest to your location and then press Enter.
Note: The script will configure your Microsoft Azure environment, making it ready for the
lab at the end of this module.
8. When the script completes, close the PowerShell command prompt and Internet Explorer.
Azure networking components

A major incentive for adopting cloud solutions
such as Azure is to enable information technology
(IT) departments to move server resources to the
cloud. This can save organizations money, and
simplify operations by removing the need to
maintain expensive datacenters with
uninterruptible power supplies, generators,
multiple fail-safes, clustered database servers, and
so on. This is particularly advantageous for small
and medium-sized companies, which might not
have the expertise to maintain their own robust
infrastructure.
Once the resources are moved to Azure, they require the same networking functionality as an on-
premises deployment, and in in specific scenarios require some level of network isolation. Azure
networking components offer a range of functionalities and services that can help organizations design
and build their cloud infrastructure services that meet their requirements.
Virtual networks
Azure Virtual Network is a fundamental component that acts as an organization’s network in Azure.
Organizations can use virtual network to connect resources. Virtual networks in Microsoft Azure are
network overlays that you can use to configure and control connectivity between Azure resources such as
VMs and load balancers.
IP addresses
VMs, Azure load balancers, and application gateways in a single virtual network require unique IP
addresses in the same way as clients in an on-premises subnet do. This enables these resources to
communicate with each other. There are two types of IP addresses that are used in an virtual network:
• Private IP addresses. A private IP address is allocated to a VM dynamically or statically from the

defined scope of IP addresses in the virtual network. This address is used by VMs in the virtual
network to communicate with other VMs in the same virtual network connected VNets/networks
through a gateway/ExpressRoute connection.
• Public IP addresses. Public IP addresses allow Azure resources to communicate with external clients,
and are assigned directly at the virtual network interface card of the VM or to the load balancer.
Subnets
You can further divide your network by using subnets for logical and security isolation of Azure resources.
Each subnet contains a range of IP addresses that fall within the virtual network address space.
Network interface card

VMs communicate with other VMs and other resources on the network by using virtual network interface
card (NIC). Virtual NICs configure VMs with private and optional public IP address. VMs can have more
than one NIC for different network configurations.
DNS
The Domain Name System (DNS) enables clients to resolve user-friendly fully qualified domain names
(FQDNs), such as www.adatum.com, to IP addresses. Azure provides a DNS system to support many name
resolution scenarios. However, in some cases, such as hybrid connection you might need to configure an
external DNS system to provide name resolution for virtual machines on a virtual network.
Azure load balancer and internal load balancer

To increase availability and scalability, you can create two or more VMs that publish the same application.
For example, if three VMs host the same website, you might want to distribute incoming traffic between
them and ensure that if one VM fails, traffic is distributed automatically to the other two. You can use an
Azure load balancer to enable this traffic distribution between VMs. In this configuration, a single
endpoint is shared between multiple VMs. The Azure load balancer automatically distributes requests
across those VMs as the requests arrive at the endpoint. You can use two types of Azure load balancers:
• Internal load balancer. The internal load balancer enables you to load balance traffic between VMs in
the same cloud service, (for classic model) or between VMs and a virtual network with a regional
scope, where the input IP address of the load balancer is private IP address.
• Internet-facing load balancer. The internet-facing load balancer enables you to load balance
incoming Internet traffic to VMs.
Application gateway
Application gateways provide load-balanced solutions for network traffic that is based on the HTTP
protocol. They use routing rules as application-level policies that can offload Secure Sockets Layer (SSL)
processing from load-balanced VMs. In addition, you can use application gateways for a cookie-based
session affinity scenario.
Traffic Manager
Microsoft Azure Traffic Manager is another load-balancing solution that is included within Azure. You can
use Traffic Manager to load balance between endpoints that are located in different Azure regions, at
hosted providers or in on-premises datacenters. These endpoints can include Azure VMs and Azure
websites. You can configure this load-balancing service to support priority or to ensure that users connect
to an endpoint that is close to their physical location for faster response.
Network security groups
You can use network security groups to provide network isolation for Azure resources by defining rules
that can allow or deny specific traffic to individual VMs or subnets. This enables you to design your Azure
virtual network to provide a network experience that is similar to an on-premises network. You can
achieve the same functionality in your Azure virtual network as you would in the on-premises networks,
such as perimeter networks (also known as DMZ or demilitarized zone).
User Defined Routes
User Defined Routes (UDR) control network traffic by defining routes that specify the next hop of the
traffic flow. You can assign User Defined Routes to virtual network subnets.
Forced tunneling
With forced tunneling you can redirect internet bound traffic back to the company’s on-premises
infrastructure. Forced tunneling is commonly used in scenario where organizations want to implement
packet inspection or corporate audit.
Regional virtual networks

Azure Virtual Network is bound to Azure subscriptions and it is not possible for multiple subscriptions to
use the same Azure virtual network. If you need to provide communications between different Azure
subscriptions, you need to create separate Azure virtual networks in each subscription and then use site-
to-site virtual network connections or the Microsoft Azure service ExpressRoute, to connect them. All new
virtual network s are regional virtual networks. This means that they can span a complete Azure region or
datacenter. This differs from the legacy implementation of virtual networks in Azure, which were restricted
to a single affinity group, allowing you to co-locate virtual networks, storage accounts and services in the
physical proximity to each other within the same area of a single datacenter. If you have older virtual
networks in your subscription, these could be tied to an affinity group. However, over time, you need to
migrate all virtual networks to regional virtual networks and remove their ties to specific affinity groups.
Cross-premises network connectivity

Virtual networks in Microsoft Azure also enable you to extend your on-premises networks to the cloud.
To extend your on-premises network, you can create a virtual private network (VPN) between your on-
premises computers or networks and an Azure virtual network. Alternatively, you can use ExpressRoute
to provide a connection to an Azure virtual network that does not cross the Internet. Using these two
methods, you can enable on-premises users to access Azure services as if they were physically located
on-premises in your own datacenter.
To connect to an Azure virtual network from an on-premises network, you can use:
• A point-to-site VPN
• A site-to-site VPN
• ExpressRoute
You also can create a VPN that connects two Azure virtual networks. These are called VNet-to-VNet
connections. You will learn more about these connection methods in Lesson 4, Configuring connections to
virtual networks.
Overview of Azure virtual networks

Azure virtual networks define an organization’s
network in the cloud, where the administrators can
have full control over IP address assignments,
name resolution, security settings, and routing
rules.
Azure Resource Manager deployment

model
When you create a VM with the Azure Resource
Manager deployment model, you then need to
place it in a virtual network to receive IP address
configurations and to connect to other VMs or
other resources that you create in Azure. Azure
Resource Manager contains a network provider that provides advanced control and network management
capabilities. With Azure Resource Manager, you can benefit from:
• Faster configuration due to resources being grouped.

• Easier management.
• Customization and deployment based on JavaScript Object Notation (JSON) templates.
Networking resources such as IP addresses, DNS settings, or NICs are managed independently and can be
assigned to VMs, Azure load balancers, or application gateways.
You can create Azure network resources by using either the Azure portal, Azure PowerShell module, Azure
command-line interface (Azure CLI), or by using deployment templates. You will learn more about how to
create these resources later in this module.
By default, you can create up to 50 virtual networks per subscription per regions, although you have the
ability to increase this limit to 500 by contacting Azure support. These virtual networks are free of charge,
but other dependent resources such as Public IP or application gateways are charged.
IP addressing in virtual networks

When you create a virtual network, you define the scope of IP addresses that you can use for allocations
to the networking resources. The scope of IP addresses can use both private IPv4 ranges and public IP
ranges.. You can use the following private IP address scopes:
• 10.x.x.x
• 172.16.x.x – 172.31.x.x
• 192.168.x.x
The allocation method of these IP addresses is dynamic by using Azure-provided Dynamic Host
Configuration Protocol (DHCP). An IP address that is allocated by DHCP has infinite duration and is
released only if you deallocate (stop) the VM. You can configure static private IP addresses from the range
of IP addresses defined within the virtual network, which will be reserved for specific VMs.
Note: When you want to assign a static IP address to on-premises computers, you can
use the Network Interface dialog box within Microsoft Windows. You must not use this method
for VMs within Azure because it will result in dropped connections and connectivity failures.
Instead, you should use the Azure portal or the Windows PowerShell command New-
AzureRmNetworkInterface with the–PrivateIPAddress switch.
For VMs that need direct access from the Internet, you can configure public IP addresses. Public IP
addresses are allocated dynamically when you create a VM, and are bound to the NICs. You also can
configure static public IP addresses and associate them to a load balancer, application gateway or a
network interface card of the VM. For example, you can use the following command to configure a public
IP address by using the static allocation method:
$publicIP = New-AzureRmPublicIpAddress -Name PublicIp -ResourceGroupName AdatumRG

-Location centralus –AllocationMethod Static -DomainNameLabel loadbalancernrp
Subnets
Often virtual networks require logical segmentation of the resources to provide different network
configurations. You can use subnets to divide your virtual network into smaller IP ranges so that the
resources organized within these subnets can be logically and securely separated. Each subnet contains a
range of IP addresses that fall within the virtual network address space. To understand subnets better,
evaluate the following scenario.
Suppose that you have resources that belong to a production environment, and resources that are used
by your developers. To separate the resources logically, you can create two subnets within Azure virtual
network, and then organize resources with IP addresses that belong to the appropriate subnet. If you
need to isolate resources further by preventing unauthorized communications between the subnets, you
can use network security groups.
Note: You will learn more about network security groups later in this module in Lesson 3,
Configuring Azure virtual network, in the topic, Configuring network security groups.
Within each subnet, the first three IP addresses and the last IP address are reserved, and you cannot use
them for VMs or cloud services. The smallest subnets that are supported use a 29-bit subnet mask. VMs
that are configured with IP addresses from one subnet can be moved to another subnet of the same
virtual network and receive different IP configurations.
DNS
Names of resources that are created in Azure can be resolved by using Azure-provided name resolution
or by using customer provided DNS server. For example, a VM can use the Azure-provided DNS to resolve
the name of any other VM in the same virtual network. However, in a hybrid scenario where your on-
premises network is connected to an Azure virtual network through a VPN, or ExpressRoute circuit, an on-
premises computer cannot resolve the name of a VM in an Azure virtual network until you configure the
DNS servers with a record for the VM. Furthermore, resources created in the same virtual network and
deployed with Azure Resource Manager (ARM) share the same DNS suffix; therefore, in most cases name
resolution by using FQDN is not required. For virtual networks that are deployed by using the Azure
classic deployment model, the DNS suffix is shared among VMs that belong to the same cloud service.
Therefore, name resolution between VMs that belong to different cloud services in the same virtual
network require the use of FQDN.
Azure classic deployment model

The Azure classic deployment model defines three types of IP addresses that are used in an Azure virtual
network:
• Dynamic IP (DIP) address. A DIP address is a dynamic internal IP address. This address is used by VMs
in the virtual network to communicate with other VMs in the same virtual network. When you have
connected a VPN to an Azure virtual network, on-premises clients communicate with virtual network
VMs by using DIPs.
• Virtual IP (VIP) address. A VIP address is a virtual IP address that is assigned to a cloud service (either
an IaaS cloud service or a platform as a service (PaaS) cloud service). This IP address is a public
Internet IP address, and it is used by external clients to communicate with the cloud service and its
VMs. All VMs within a single cloud service have the same VIP address.
• Instance-level public IP (ILPIP) address. A ILPIP address is associated directly with the VM, and enables
direct communication with a VM without relying on VIP address.
In the Azure classic deployment model, you can create VMs in Azure without using virtual networks.
However, you must place each VM in an IaaS cloud service. You can create each VM in a separate cloud
service or you can add two or more VMs to a single cloud service. VMs in the same IaaS cloud service can
communicate directly. VMs in different IaaS cloud services can only communicate through cloud service
endpoints that have specific port numbers. VMs can also communicate with PaaS cloud services though
their endpoints. This situation becomes more flexible when you consider Azure virtual networks where a
VM in a virtual network can communicate directly with any other VM in the same virtual network, even if
it is in a different IaaS cloud service.
Note: You will learn more about networking features in the Azure classic deployment mode
in the Lesson 5, Overview of Azure Networking in IaaS v1, later in this module.
Cross-premises network connectivity

When you move a server to the cloud, you move it further from the users on your premises. This physical
move should not place any barrier between the users and the resources they need, to do their job. You
can use a VPN connection to remove any potential connectivity barriers. A VPN can connect your on-
premises network to an Azure virtual network, and all the VMs and PaaS cloud services it contains. This
connection means that users can connect to Azure resources as if they were local.
To connect to an Azure virtual network from an on-premises network, you can use one of the following
methods:
• A point-to-site VPN. This is a VPN that connects individual computers to an Azure virtual network.
You must create a VPN connection from each on-premises computer that you want to connect to the
Azure virtual network.
• A site-to-site VPN. This is a VPN that connects an on-premises network and all its computers to an
Azure virtual network. To create this connection, you must configure a gateway and IP routing in the
on-premises network; it is not necessary to configure individual on-premises computers.
• ExpressRoute. An ExpressRoute connection is a dedicated service that does not connect across the
Internet. Instead, it uses a private connection to Azure datacenters, provided by a network provider.
By using ExpressRoute, you can increase security, reliability, and bandwidth.
Note: In the time of the writing of this course, a point-to site VPN is supported in both
Service Management and Azure Resource Manager deployment model. Azure Resource
Manager-based configuration is not available in Azure portal, but requires the use of Azure
PowerShell.
You also can create a VPN that connects two Azure virtual networks. This is called a VNet-to-VNet
connection.
Whenever you want to connect to an Azure virtual network, you must provision a VPN gateway in Azure.
The VPN gateway routes traffic between VMs and PaaS cloud services in the virtual network, and
computers at the other end of the connection.
Overview of network interfaces

Azure virtual machines that need to communicate
by using IP addresses require a virtual network
interface card (NIC). You can assign these NICs to
the VMs and Azure load balancers, and configure
these resources with private and public IP
addresses.
If you assign a public IP address to a NIC, the VM

that uses that NIC is exposed directly on the
internet and can communicate with internet
resources without using an Azure load balancer.
Azure Resource Manager defines the NIC as a
stand-alone networking resource, which can be
assigned to VMs and Azure load balancers. Each NIC has several properties that can provide different
network configurations. Some of the most important properties are:
• virtualmachine. Specifies the current VM that is associated with that NIC.
• macaddress. Presents the media access control (MAC) address for the NIC.
• networksecuritygroup. Provides reference to the network security group resource.

• dnsSettings. Provides DNS settings for the NIC.
• ipconfigurations. Contains information for IP address configuration of the NIC.
IP address configuration is bound to a NIC by using child object ipConfigurations. By default, NICs are
configured with dynamic private IP address from the appropriate subnet of the virtual network. You also
can specify a static private IP address. Additionally, you can configure the NIC with a public IP address
that allows direct communication to the VM that uses that NIC. If you create a VM in the portal, by using
the default settings, you assign dynamic public IP address that allows direct communications to VMs from
the Internet. Furthermore, you can associate custom DNS names to the public IP address. You can
communicate with VMs from the Internet or with other virtual networks by using a registered public DNS
name. You can create a NIC that is configured with a public IP address in the Azure PowerShell module by
using the NewAzureRMNetworkInterface command with the -PublicIpAddress switch.
VMs can have more than one NIC adapter that links the VM with the virtual network. The number of NICs
you can attach to a VM depends on its size. For example, a VM that is based on a D2 size can have 2 NICs,
and a D4-based VM can have a maximum of 8 NICs. Multiple NICs configuration is common for virtual
appliances that provide additional control of traffic in virtual networks.
Additional Reading: For more information, refer to “Create a VM with multiple NICs” at:
http://aka.ms/Yseiy5.
Overview of private IPs

Private IP addresses are required for resources
that you configure to use virtual networks for IP
allocations such as VMs, internal load balancers,
or application gateways. With private IP
addresses, these resources communicate between
themselves on a virtual network and potentially
with on-premises resources, if you have
configured a virtual network with VPN gateway or
ExpressRoute circuit.
Azure assigns private IP addresses by using DHCP

protocol as either dynamic allocation method, or
by using the DHCP reservation as static allocation
method. Dynamic allocation is based on the scope of the IP addresses that you configure for virtual
network subnets. In this case, the lease is infinite, which means that VMs keep that IP address for their
lifetime. The only exception to this rule is when you stop and deallocate VMs. When this happens, they
release the IP address, which then can be reassigned to other resources in the virtual network. To avoid
this situation—for example, if a VM hosts a DNS service or is a domain controller—you can allocate IP
addresses by using the static allocation method.
Static private IP addresses also are required when you control traffic flow by using a firewall that defines
the rules based on a particular IP address. You can assign static private IP addresses to existing VMs either
during the VM creation process, or after you have created the VM. Private IP addresses are allocated for
the NIC that is assigned to a VM. You can use both the Azure portal and the Azure PowerShell module to
allocate static private IP address.
During allocation, you need to specify the virtual network and the subnet from which you want to
configure static private IP address.
The following commands retrieve values for a virtual network and a subnet, and then save these values in
the variable $vnet and $subnet:
$vnet = Get-AzureRmVirtualNetwork -ResourceGroupName AdatumRG -Name AdatumVNet

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

centralus -SubnetId $vnet.Subnets[0].Id -PrivateIpAddress 192.168.0.10
To add a static private IP address during VM creation you use the following PowerShell command:
Add-AzureRmVMNetworkInterface -VM $vm -Id $nic.Id

This command stores configuration parameters for the VM in the $vm variable, and network-related
configuration parameters for the NIC adapter in the $nic variable. To add a static private IP address to an
existing VM you can use the following command:
Set-AzureRmNetworkInterface -NetworkInterface $nic
The Azure classic deployment model which, in the context of IaaS is also known as IaaS v1, supports
allocation of private IP addresses to VMs and PaaS cloud services roles. The model also supports both
dynamic and static IP allocation methods. However, Azure cloud services are not compatible with IaaS
version 2 (v2) resources. Therefore, you cannot, for example, deploy a cloud service to an IaaS v2 virtual
network.
Overview of load balancers
Resources built in Azure, such as VMs or Web

Apps, have the same requirements as on-premises
workloads for achieving high availability and
increased performance.
Azure load balancer

You can use an Azure load balancer to provide
availability and scalability for the VMs that are
part of the load balancer set. Azure Load Balancer
provides functionality similar to hardware load
balancers, by eliminating single points of failure
(application or hardware) and increasing uptime
during planned maintenance or upgrades.
You can use two types of Azure Load Balancer:
• ILB. The internal load balancer enables you to load-balance traffic between VMs in the same virtual
network or a virtual network connected to other networks via Site-to-Site VPN, VNet-to-VNet
connection, or ExpressRoute.
• Internet-facing load balancer. The internet-facing load balancer enables you to load balance
incoming Internet traffic to VMs.
Internet-facing load balancer

Internet-facing load balancers distribute traffic that is designated to the public IP address and public port
of the VM or service, towards the balanced set of private IP addresses and ports for the VMs and services
that are part of the load-balanced set. Both the classic and the resource deployment models support load
balancer.
The Azure classic deployment model can load balance incoming traffic that is designated to the virtual IP
address that is bound to the cloud service, which can contain either IaaS v1 VMs or PaaS web and worker
roles. A common scenario for when you would use an internet-facing load balancer is when you need to
provide a highly available and a high performance web applications solution. For example, if three VMs
host the same website, you might want to distribute incoming traffic between them and ensure that if one
VM fails, traffic is distributed automatically to the other two VMs. You can use an Azure load balancer to
enable this traffic distribution between VMs. In this configuration, a single endpoint is shared between
multiple VMs. The Azure load balancer distributes incoming traffic automatically across those VMs as it
arrives at the load balanced endpoint. ARM also provides support for Azure load balancer. ARM, does not
need a cloud service, since the IP address—either private or public—is bound directly to the load balancer
resource. Incoming traffic that is directed to the IP address of the load balancer passes several load
balancer rules and inbound network address translation (NAT) rules. Afterwards, traffic is delivered to the
NIC attached to one of the backend VMs or services. You can use NAT rules to control how inbound and
outbound communication is managed. They define the inbound traffic flow through the front-end IP and
direct it to the back end IP of a specific virtual machine instance.
To configure a load balancer in ARM, you need to provide the following details:
• Front-end IP configuration. Specify incoming traffic that needs to be load balanced.
• Backend address pool. Specify the VM NICs that receive network traffic from the load balancer.
• Load balancing rules. Specify a rule to match the front-end IP address and port with the backend IP
address and port that is associated with VMs. You can have more than one rule.
• Probes. Configure the health status probe for the VM instances.

• Inbound NAT rules. Specify rule for the traffic flow from a public port on the load balancer to the
backend port for a specific virtual machine in the back end address pool. You can have more than
one NAT rule.
You can create a load balancer in ARM by using Azure PowerShell, or by using ARM templates. You can
download the existing ARM template for creating a load balancer from GitHub.
Additional Reading: For more information, refer to Load Balancer with Inbound NAT Rule:
http://aka.ms/Sihgqz.
For example, to create a virtual network, a virtual network subnet, and an external load balancer that will
balance incoming network traffic on port 443 and provide connectivity on port 3389 to two back end
VMs, you would use the following procedure:
Connect to your subscription from Azure PowerShell

1. Start Azure PowerShell and sign in to your Azure subscription:
2. If there are multiple subscriptions associated with your account, select the target subscription:
Set-AzureRmContext –SubscriptionName <Name of your subscription>
Create a resource group and virtual network

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

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

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

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

-Location centralus –AllocationMethod Static -DomainNameLabel loadbalancernrp
Create front-end and backend IP Address Pool

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

-PublicIpAddress $publicIP
2. Create a backend address pool named LB-backend, and then store the value in the variable
$beIPPool:
$beIPPool = New-AzureRmLoadBalancerBackendAddressPoolConfig -Name LB-backend
Create a load-balancer rule, a NAT rules, a probe, and a load balancer

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

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

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

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

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

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

-Location centralus -PrivateIpAddress 192.168.1.6 -Subnet $backendSubnet
-LoadBalancerBackendAddressPool $lb.BackendAddressPools[0] -
LoadBalancerInboundNatRule $LB.InboundNatRules[0]
$backendnic2= New-AzureRmNetworkInterface -ResourceGroupName NRP-RG -Name lb-nic2-be
-Location 'West US' -PrivateIpAddress 192.168.1.7 -Subnet $backendSubnet
-LoadBalancerBackendAddressPool $lb.BackendAddressPools[0] -
LoadBalancerInboundNatRule $LB.InboundNatRules[1]
2. Update the existing NIC configuration with a backend IP address pool:
$backednic1.IpConfigurations[0].LoadBalancerBackendAddressPool=$beIPPool
$backednic2.IpConfigurations[0].LoadBalancerBackendAddressPool=$beIPPool
Set-AzureRmNetworkInterface –NetworkInterface $backednic1
Set-AzureRmNetworkInterface –NetworkInterface $backednic2
Internal load balancer

An internal load balancer enables you to run highly available services behind a private IP address. You can
use internal load balancers in both classic and resource deployment models to balance traffic that is
designated to specific IP addresses and specific Transmission Control Protocol (TCP) or User Datagram
Protocol (UDP) ports. You can use internal load balancer to load-balance traffic in the following scenarios:
• Between VMs within a cloud service (Azure classic deployment model)
• Between VMs across different cloud services that are part of the same virtual network (Azure classic
deployment model)
• Between on-premises computers and VMs in a cross-premises virtual network
• Between multi-tier applications that have backend tiers that are not on the Internet, but require load-
balanced traffic from the Internet-facing tier
Application gateway
Another form of a load-balancing solution for HTTP traffic is provided by application gateway. Application
gateway provides routing and load-balancing services at the application layer, and is commonly known as
a layer-7 load balancer. You can use application gateway for the following scenarios:
• Load balancing and high availability for HTTP traffic. Application gateway uses routing rules for HTTP
traffic, where the incoming traffic from a public IP address is delivered to the backend configuration,
which can be a VM, a cloud service, a web app or an external IP address.
• SSL offload. After uploading a server certificate and creating a listener on port 443, you then can
configure application gateway with routing rules that terminate an SSL session at the gateway instead
of the web farm.
• Cookie-based affinity. Application gateway redirects requests from the client to the same VM in the
web farm.
• URL path based routing. Application Gateway can route the traffic to back-end server pools based on
the URL path of the request.
Traffic Manager
Traffic Manager is another load-balancing solution that is available in Azure, and that can load balance
between endpoints that are located in different Azure regions, hosted providers or even in your on-
premises datacenters. These endpoints can include IaaS cloud services, PaaS cloud services, and instances
of App Service. You can configure load balancing to support failover or to ensure that users connect to an
endpoint that is close to their physical location for faster response. You will learn how to configure Traffic
Manager in Module 5.
Overview of Azure DNS

Azure DNS is a hosted service that allows
organizations to host their DNS domains and
provides name resolution using the Microsoft
global infrastructure. Azure DNS uses anycast
networking, which enables the fastest response to
name queries from the closest DNS server. Azure
DNS uses the new Azure Resource Manager
deployment model. You can manage Azure DNS
with the PowerShell command line interface, but
not with the Azure classic portal. You can use
Azure DNS as an authoritative server for responses
that are directed to your DNS domain name, or as
an additional DNS server in your DNS infrastructure.
Note: You cannot use Azure DNS to purchase new domains, but you can use it only to host
already owned public domains.
In both cases, delegation for your zone at your registration authority should point to the name servers
that host your Azure DNS zone. Name servers in Azure DNS are allocated automatically from the pool
during zone creation. You can view currently allocated name servers for your zone by running the
following Azure PowerShell command:
Get-AzureRmDnsRecordSet –Name “@” –RecordType NS –Zone $zone
The $zone variable should contain your created Azure DNS hosted zone.
The Process for creating an Azure DNS zone is as follows:
1. Start Microsoft Azure PowerShell and use the following command to sign in to your Azure
subscription:
2. If there are multiple subscriptions associated with your account, select the target subscription:
Set-AzureRmContext –SubscriptionName <Name of your subscription >

4. Create a DNS Zone:
New-AzureRmDnsZone -Name adatum.com -ResourceGroupName AdatumRG
5. Retrieve the SOA and the NS record for the zone:
Get-AzureRmDnsRecordSet -ZoneName adatum.com -ResourceGroupName AdatumRG
Once you create the zone, you can support all common DNS record types, such as A, AAAA, CNAME, MX,
NS, SOA, SRV and TXT. The following table describes the function of each type of record.
Record type Full Name Function
A (IPv4) Address Maps a host name such as mail.adatum.com to an IP

AAAA (IPv6) address, such as 131.107.10.10.
CNAME Canonical name Points one host record, such as adatum.ftp.adatum.com,

to another host record, such as
mail.lucernepublishing.com, or even another host
record in another domain, such as www.contoso.com.
MX Mail exchange Points to the host that will receive mail for that domain.
MX records must point to an A record, and not to a
CNAME record.
NS Name server Delegates a DNS zone to the specified authoritative

name server.
SOA Start of Authority Defines the authoritative record for the zone.
SRV Service Locates hosts that are providing specific services, such
as the Session Initiation Protocol (SIP) endpoint.
TXT Text Records a human-readable text field in DNS.
Records in Azure DNS are created as a record set, which is a collection of DNS records with the same name
and same type. The process of creating a record set that contains resource records with specific values in
the Azure DNS zone is a two-step process:
1. Create a record set by using the command New-AzureDnsRecordSet with the values for record
type, zone name, resource group, and TTL. For example, the following commands create a record set
for the relative name www in the zone adatum.com, and with a Time to Live (TTL) value of 60
seconds. The output of the command is stored in the variable $AdatumRS:
$AdatumRs=New-AzureRmDnsRecordSet -Name "www" -RecordType "A" -ZoneName "adatum.com"

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

Lesson 2
Implementing and managing virtual networks
Azure virtual networks are fundamental components of Azure networking. They present customer
networks in the cloud, and thus they should follow the similar principles of design and security as on-
premises networks. Choosing the right address space at the beginning is critical to overall planning
activities, especially if you plan to integrate Azure networks with on-premises resources. In this lesson, you
will review how to create virtual networks, and manage them. You can create and configure virtual
networks either by using the Azure portal, Azure PowerShell, or by using ARM deployment templates.
Lesson Objectives
• Describe how to plan Azure virtual networks.
• Describe how to create and configure virtual networks by using the Azure portal.
• Describe how to create and configure virtual networks by using PowerShell commands.
• Describe how to create and configure virtual networks by using deployment templates.
Planning for Azure virtual networks

You can control the private IP addresses that are
assigned to VMs and cloud services within an
Azure virtual network by specifying an IP
addressing scheme. Planning an IP addressing
scheme within Azure virtual network is similar to
planning an on-premises IP addressing scheme.
The same ranges often are used and the same
rules apply. However, there are conditions that are
unique to Azure virtual networks.
Selecting private address spaces

You can use both private and public address space
for defining the address pool that will be used in
VNet.
The RFC 1918 standard defines three private address spaces that are never used on the Internet.
Administrator’s use these address ranges behind NAT devices to ensure unique addresses used within
intranets do not prevent communication with Internet servers. These three address spaces are commonly
used in the Azure VNets.
• 10.0.0.0/8. Includes all addresses from 10.0.0.1 to 10.0.0.255
You can also use public IP address space in CIDR notation for Virtual Network, and they are treated as
part of the private virtual network IP address space.
When you specify an address space for a virtual network, you can specify a much smaller range within one
of the private address spaces. For example, if you specify the address space 10.1.1.0/24, it means that only
addresses from 10.1.1.1 to 10.1.1.255 should be allocated to your virtual network.
In a cloud-only virtual network, you can specify any address range, both RFC 1918 private spaces and
public IP address space. However, if you plan to connect to the virtual network with a VPN or
ExpressRoute, you must ensure that the address space is unique and does not overlap with any of the
ranges that are already in use on-premises or in other virtual networks.
Best Practice: Always plan to use an address space that is not already in use in your
organization, whether it be on-premises or in other virtual networks. Even if you plan for a virtual
network to be cloud-only, you might want to make a VPN connection to it later. If there is any
overlap in address spaces, you will have to recreate the virtual network.
Choosing subnets
You also must subdivide the VMs and cloud services in your virtual network by configuring one or more
subnets. The range you specify for a subnet must be contained entirely within its parent virtual network’s
address space. Within each subnet, the first three IP addresses and the last IP address are reserved and
cannot be used for VMs or cloud services. The smallest subnets that are supported use a 29-bit subnet
mask.
Using static private IP addresses

Because clients use DNS to resolve a name to an IP address, many VMs and services can receive new
dynamic private IP addresses without interrupting their service to users. In addition, because DHCP leases
are infinite in Azure virtual networks, IP addresses rarely change. However, sometimes an IP address
change does occur. For example, if a new VM is created while another VM is in the stopped (deallocated)
state the new VM might take the old VM’s original address.
If you expect an IP address change to cause problems for your server, you can use a static private IP
address for that VM. For example, a DNS server should have a static IP address, because clients will not be
able to locate it if its address changes.
Creating virtual networks by using the Azure portal

To create a virtual network in the , perform the
following procedure:
1. Sign in into the Azure portal.

2. In the navigation menu on the left, click New,
select Networking, and then click Virtual
network.
3. In the Virtual network blade, verify that

Resource Manager deployment model is
selected, and then click Create.
4. In the Create virtual network blade, in the

Name text box, type a descriptive name for
the virtual network.
5. In the Address space box, select the IP address range by using Classless Interdomain Routing
(CIDR) notation.
6. In the Subnet name text box, type a descriptive name for the subnet.
7. In the Subnet address range box, choose the IP address range for the subnet by using CIDR
notation.
8. In the Subscription drop-down list box, select the right Azure subscription in which you want to
create a virtual network.
9. In the Resource group box, either create a new resource group or select an existing one.
10. In the Location drop-down list box, select a location near your users, and then click the Create
button.
After the virtual network provisioning is complete, you can configure it further by creating additional
subnets or setting up a DNS server address.
To modify additional setting in the Azure portal, perform the following procedure:
1. Select your newly created virtual network. In the Settings blade, you can configure several additional
features of the virtual network.
2. In the Settings blade, click the Properties link, and then identify the Resources ID of the virtual
network, the location of the data center, the subscription name, and the subscription ID.
3. In the Settings blade, click the Address space link, and then provide additional range of IP addresses
that you can configure on that virtual network.
4. In the Settings blade, click the Subnets link to create an additional subnet.
5. In the Subnet blade, click Add to add a new subnet.
6. In the Add Subnet blade, in the Name text box, type a descriptive name. In the Address range
(CIDR block) box, type the IP address range for the subnet by using CIDR notation, and then click
OK to confirm creation of the subnet.
7. In the Settings blade, click the DNS servers link to configure DNS server settings for the virtual
network.
8. In the DNS servers blade, click Custom DNS. In the Primary DNS server text box, type your custom
DNS server IP address, and then click Save to confirm the modification of the DNS server IP address.
9. In the Settings blade for the virtual network, in the Resource Management section, click the Users
link to modify the Role Based Access Model for this resource.
10. In the Settings blade, in the Resource Management section, click the Tags link to add a custom tag
to the VM.
Note: This procedure explains how to create a virtual network in an Azure Resource
Manager deployment model. You will learn how to create a virtual network by using the Azure
classic deployment model in the last lesson of this module, Overview of Azure Networking in
IaaS v1.
Creating virtual networks by using PowerShell

You can create Azure virtual networks by using
the Azure PowerShell module that is currently
available in two releases: 1.0, and 0.9.8. The 1.0
release uses different commands that follow the
naming pattern “{verb}-AzureRm{noun}”, for
example Get-AzureRmVirtualNetwork, whereas
the 0.9.8 release does not include Rm in the
command, for example (Get-
AzureVirtualNetwork).
To create a virtual network by using the Azure

PowerShell Module, perform the following steps:
1. Start Microsoft Azure PowerShell and sign in

to your subscription:
2. If there are multiple subscriptions associated with your account, select the target subscription in
which you are going to create a virtual network:
4. Create a new VNet named AdatumVnet, assign an address space (in this example 192.168.0.0/16),
and store a reference to the new virtual network in the $vnet variable:

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

-AddressPrefix 192.168.1.0/24

Creating a virtual network by using a deployment template

You can download one of the existing ARM
templates for creating a virtual network from
GitHub. On the GitHub website, you can find
different templates, APIs, software development
kits (SDKs), and open source projects from Azure.
First, you need to download the appropriate ARM

template, which is a json file, and identify the
parameters that you can modify with custom
values. You can update the values for the
parameters directly in the azuredeploy-
parameters.json file. Finally, you deploy the ARM
template either by using the Azure PowerShell
module, Visual Studio, or by using deep link directly from Azure portal.
To create a virtual network by using ARM templates, perform the following procedure:
1. Go to https://github.com/Azure/azure-quickstart-templates and search for the appropriate

template, for example Virtual Network with two Subnets.
2. Save the azuredeploy.json file in RAW data format.
3. Identify the parameters to which you want to assign custom values that will be used during
deployment:
o vnetName. Provides the name of the virtual network.
o vnetAddressPrefix. Defines the IP address range in CIDR format.
o subnet1Name. Defines the name for the first subnet.
o subnet1Preffix. Defines the IP address range in CIDR notation for the first subnet.
o Subnet2Name. Defines the name for the second subnet.
o Subnet2Preffix. Defines the IP address range in CIDR notation for the second subnet.
o location. Specifies the Azure region where the virtual network will be created.
4. Check the resources section to identify the resources created in ARM.
o type. Provides the resource type created in the ARM. In this template, virtual networks are
represented by the resource type Microsoft.Network/virtualNetworks.
o name. Provides name for the resource.

o location. Specifies the Azure region that will be provided as input by the user during the
deployment.
o properties. Defines the properties, such as address space and subnet during the creation of the
virtual network.
5. Download azuredeploy-parameters.json in RAW format, and then open it in Notepad.

6. Modify the parameters with your required values and save the changes.
For example, modify the values for the properties of the ARM template that you will use for creation
of the virtual network:
Modify the azuredepeploy-parameters.json file

{
"location": {
"value": "Central US"
},
"vnetName": {
"value": "AdatumVNet"
},
"vnetAddressPrefix": {
"value": "10.0.0.0/16"
},
"subnet1Name": {
"value": "AdatumSubnet1"
},
"subnet1Prefix": {
"value": "10.0.0.0/24"
},
"subnet2Name": {
},
"subnet2Prefix": {
"value": "10.0.1.0/24"
}
}
7. Start Microsoft Azure PowerShell and sign in to your subscription using the following command:
which you are going to create virtual network:
9. Create a new resource group using the following command:
10. Run the New-AzureRmResourceGroupDeployment cmdlet to deploy the new virtual network by
using the template and parameter files that you downloaded and modified in steps one to six. For
example:
New-AzureRmResourceGroupDeployment -Name AdatumVNetDeployment -ResourceGroupName

AdatumRG `
-TemplateFile .\azuredeploy.json -TemplateParameterFile .\azuredeploy-
parameters.json
Demonstration: Deploying a virtual network by using Azure portal

Demonstration Steps
1. Open Internet Explorer and go to http://aka.ms/Mt32e4.
2. Save the azuredeploy.json file in RAW format to the D:\Demofiles\Mod02 folder.
3. Open the file in Visual Studio 2015.
4. In the Visual Studio 2015 interface review the parameters that you can modify with your custom
values that you will use during deployment (but do not make any changes at this point):
o vnetName. Provide name of the virtual network.
o vnetAddressPrefix. Define the IP address range in Classless Interdomain Routing (CIDR) format.
o subnet1Name. Define the name for the first subnet.
o subnet1Preffix. Define the IP address range in CIDR notation for the first subnet.
o Subnet2Name. Define the name for the second subnet.
o Subnet2Preffix. Define the IP address range in CIDR notation for the second subnet.
o location. Specify the Azure region where the virtual network will be created.
5. Review the resources section to identify the schema of the resources created in Azure Resource
Manager (ARM) without making any changes:
o type. Provides the resource type created in the ARM. In this template virtual networks are
represented by the resource type. Microsoft.Network/virtualNetworks.
o name. Provides name for the resource.

o location. Specifies the Azure region that will be provided as input by the user during the
deployment.
o properties. Define the properties, such as address space and subnet, during the creation of the
virtual network.
6. Download azuredeploy.parameters.json in RAW format to the D:\Demofiles\Mod02 folder and

then open it in Visual Studio.
7. Modify the parameters with the values listed in the code content below, and then save the changes.
Modify the values for the properties of the Azure Resource Manager (ARM) template that can be used
for creation of the virtual network:
Modify the azuredepeploy-parameters.json file

{
"location": {
"value": "<enter here the Azure region that will be used as the primary location for the demos
and labs in this module>"
},
"vnetName": {
"value": "AdatumDemoVNet"
},
"vnetAddressPrefix": {
"value": "10.0.0.0/16"
},
"subnet1Name": {
},
"subnet1Prefix": {
"value": "10.0.1.0/24"
},
"subnet2Name": {
},
"subnet2Prefix": {
"value": "10.0.1.0/24"
}
}
8. Use the following command to start Microsoft Azure PowerShell and sign in to your subscription:
9. If you have multiple subscriptions, select the subscription in which you are going to create the virtual
network by using the following command (replace ‘Name of your subscription’ with the actual name
of your subscription and make sure to enclose the name of your subscription in single quotes):
Set-AzureRMContext –SubscriptionName ‘Name of your subscription’
10. Create a new resource group by using the following command:
New-AzureRMResourceGroup –Name AdatumDemoRG –Location "<enter here the Azure region that
will be used as the primary location for the demos and labs in this module>"
11. Run the New-AzureRmResourceGroupDeployment cmdlet to deploy the new virtual network by
using the template and parameter files that you downloaded and modified in steps 1 through 6:
New-AzureRmResourceGroupDeployment -Name AdatumVNetDeployment -ResourceGroupName

AdatumDemoRG -TemplateFile D:\Demofiles\Mod02\azuredeploy.json -TemplateParameterFile
D:\Demofiles\Mod02\azuredeploy.parameters.json
12. Verify that the new virtual network is created by using the following command:
Get-AzureRmVirtualNetwork -ResourceGroupName AdatumDemoRG -Name AdatumDemoVNet

Lab A: Using a deployment template and Azure

PowerShell to implement Azure virtual networks
Scenario
A. Datum Corporation’s Azure VMs currently reside on an IaaS v1 virtual network in the branch region. To
prepare for deployment of IaaS v2 VMs, A. Datum must deploy an IaaS v2 virtual network in the
Headquarters region. You determined this is a relatively straightforward process if you use an existing
deployment template and modify its parameters during deployment. However, you want to also test
deployment of a virtual network by using Azure PowerShell. In addition, you need to prepare your
existing IaaS v1 virtual network for establishing connectivity to the IaaS v2 virtual network by creating a
virtual network gateway and deploy a test IaaS v2 VM to the virtual network deployed by using the
template.
Objectives
• Create a virtual network by using deployment templates.
• Create a virtual network by using PowerShell.
Lab Setup

User name: Student
Password: Pa$$w0rd
Before starting this lab, ensure that you have performed the Preparing the Environment demonstration
tasks at the beginning of the first lesson in this module, and that the setup script has completed.
Exercise 1: Creating an Azure virtual network by using a deployment

template
Scenario
A. Datum now wishes to implement virtual networks for the A. Datum headquarters and branch resources.
You have been asked to configure these virtual networks by using deployment templates from GitHub.
1. Access the template on GitHub.
2. Load the template into new deployment on the Azure portal.
3. Run the deployment from the Azure portal.
 Task 1: Access the template on GitHub

1. Ensure that you are logged on to MIA-CL1 as Student with the password Pa$$w0rd.
2. Start Internet Explorer and browse to the following address: http://aka.ms/Mt32e4.
3. Open a GitHub template that you can use to create a virtual network with two subnets.
 Task 2: Load the template into new deployment on the Azure portal
1. In Internet Explorer, under Virtual Network with two Subnets, click Deploy to Azure.
2. When prompted, sign in using the Microsoft account associated with your Azure subscription.
3. In the Azure portal, in the Custom deployment blade, click the Edit Template link.
4. Review the structure of the JSON file. Examine the placeholders for values that can be edited during
the deployment. This template contains the following parameters that you can edit: vnetName,
vnetAddressPrefix, subnet1Name, subnet1Prefix, subnet2Name, subnet2Prefix.
5. Review the content under resources to identify type of the resource, its name and properties.
6. Click Discard to close the Edit Template blade.
Note: If the template fails to load into the Azure portal, navigate to the following URL:
http://aka.ms/Fpqovq. Then, select and copy all the text. Paste the copied text into the Edit
Template blade, and then perform steps 4 and 5 to review the template.
 Task 3: Run the deployment from the Azure portal

1. In the Custom deployment blade click Edit Parameters.
2. Type the following information for the Parameters, and then click OK.
o VNETNAME: HQ
o VNETADDRESSPREFIX: 10.0.0.0/16
o SUBNET1NAME: Subnet1
o SUBNET1PREFIX: 10.0.0.0/24
3. In the Custom Deployment blade, under the Resource Group section, ensure that New appears in
the drop-down list. In the New resource group name field, type AdatumLabRG to create a new
Resource group with that name.
4. In the Custom Deployment blade, under Resource group location drop-down list, select
<Location1>.
5. In the Custom Deployment blade, click Legal Terms link. Review the Terms of use, and then click
Purchase.
6. In the Custom Deployment blade, click Create to create the new virtual network.
7. Verify that provisioning of the new virtual network with name HQ completed successfully.
Results: After completing this exercise, you should have created virtual networks for A. Datum HQ.
Exercise 2: Creating a virtual network by using PowerShell

Scenario
A. Datum is expanding their services in Azure by using both declarative and imperative deployment
methods and they ask you to test provisioning of a new network by using Azure PowerShell.
The main task for this exercise is as follows:
1. Create a virtual network by using PowerShell.
 Task 1: Create a virtual network by using PowerShell

1. From the taskbar start Windows PowerShell and sign in to your subscription by using the Login-
AzureRMAccount command.
2. Select your subscription by using the Set-AzureRMContext command, and then use New-
AzureRMResourceGroup command to create a new resource group named AdatumTestRG in the
primary Azure region provided by the instructor.
3. By using the New-AzureRMVirtualNetwork command, create a new virtual network named

AdatumTestVnet with the address space 10.0.0.0/16 in the same region as the resource group.
4. Add a subnet named FrontEnd with the IP range of 10.0.0.0/24 to the virtual network
AdatumTestVNet.
Results: After completing this exercise, you should have created a test virtual networks for A. Datum by
using Azure PowerShell.
Exercise 3: Configuring virtual networks

Scenario
As part of expanding their network environment, A. Datum needs to prepare for connecting IaaS v1
virtual networks and IaaS v2 virtual networks by creating a virtual network gateway on an IaaS v1 virtual
network. You also need to test provisioning of an Azure IaaS v2 VM onto an IaaS v2 virtual network.
1. Create an IaaS v1 virtual network gateway.
2. Deploy an IaaS v2 virtual machine into an IaaS v2 virtual network.
 Task 1: Create an IaaS v1 virtual network gateway

1. Switch to Internet Explorer and in the new tab, navigate to the classic Azure portal.
2. If you are prompted to sign-in, use an account that is either a Service Admin or a co-admin of your
Azure subscription.
3. From the navigation bar, select networks, and then click ADATUM-BRANCH-VNET.
4. Create a new dynamic routing gateway.
Note: The creation of the VPN gateway could take 30 - 35 minutes to complete.
5. The creation of the VPN gateway could take 30 - 35 minutes to complete.

 Task 2: Deploy an IaaS v2 virtual machine into an IaaS v2 virtual network

1. Right-click the Windows PowerShell shortcut in the taskbar and click Run ISE as Administrator.
press Enter:
CD D:\Labfiles\Lab02\Starter
3. At the command prompt, type the following command, and then press Enter:
.\CreateVirtualMachine.ps1
Note: The command starts with dot backslash.
4. When prompted to sign in (twice), type in the user name and the password which is either the Service
Administrator or a Co-Admin in your Azure subscription.
5. If you have multiple subscription, when prompted, type in the number corresponding to the
subscription to which you deployed the virtual network in the first exercise of this lab and press Enter.
Note: The script takes about 10 minutes to complete.

The script deploys an IaaS v2 virtual machine named ARMSrv2 onto the first subnet of the IaaS v2
HQ virtual network you provisioned earlier in this lab.
6. The script takes about 10 minutes to complete.
7. The script deploys an IaaS v2 virtual machine named ARMSrv2 onto the first subnet of the IaaS v2 HQ
virtual network you provisioned earlier in this lab.
Results: After completing this exercise, you should have created a virtual network gateway on the existing
IaaS v1 virtual network and deployed a virtual machine to the newly created IaaS v2 HQ virtual network.
Question: What are the two methods that you can use to create an Azure virtual network?
Lesson 3
Configuring Azure virtual network
Azure virtual network has many similarities with on-premises infrastructure. You can control name
resolutions by deploying your own DNS server and define routes to further control the network traffic.
Security policies, packet inspection, and multiple tier network design provide you with enterprise-ready
networking functionality that can address your organizational requirements.
Lesson Objectives
• Explain how to plan name resolutions in Azure virtual network.
• Describe how to configure user-defined routes.
• Describe how to configure forced tunneling.
• Describe how to configuring network security groups.
Configuring name resolution in Azure virtual network

Name resolution is the process by which a
computer name is resolved to an IP address. Users
find it difficult to remember IP addresses when
they need to identify remote computers for
communication. Azure provides a name resolution
service that enables VMs and cloud services within
Azure to communicate by name. However, some
configurations exceed the reach of the Azure
name resolution service. You must plan name
resolution carefully to ensure that all computers
and VMs can communicate between themselves
and with the Internet.
Consider the following scenarios while planning name resolution:
• VMs IaaS v1 or role instances in the same cloud service. VMs can resolve the names of all other VMs
in the same cloud service automatically by using Azure-provided name resolution.
• VMs IaaS v2 in the same virtual network. VMs deployed by using ARM, and that reside in the same
virtual network can use either Azure-provided name resolution or your own DNS server.
• VMs are in different cloud services but within a single virtual network. These VMs can resolve IP
addresses for each other by using the internal Azure name resolution service and their FQDNs.
Alternatively, use your own DNS system to support this scenario.
• Hybrid connectivity between VMs in a virtual network and on-premises computers. To support this
scenario you must use your own DNS server.
• Hybrid connectivity between VMs in different virtual networks. To support this scenario you must use
your own DNS system.
• Connectivity between on-premises computers and public endpoints. If you publish an endpoint from
a VM in an Azure virtual network, the Azure-provided external name resolution service resolves the
public VIP address. This also applies for any internet-connected computers that are not on your
premises.
• Reverse lookup of internal IP addresses. This name resolution is supported only with your own DNS
server.
Azure-provided name resolution

Azure-provided name resolution does not require any configuration and is highly-available by design. For
virtual networks that you deployed in the ARM mode, DNS suffix is common across the virtual network.
Therefore, the FQDN does not need to be specified during internal communications. Furthermore, you
can assign DNS names to either the NIC or the VM. In the classic deployment model, the DNS suffix is in
the form name.cloudapp.net, and is shared across all the VMs and role instances that belong in the same
cloud service. Communications between VMs residing in different cloud services require FQDN.
Name Resolution by using your own DNS server

If you are planning to use your own DNS system, you must ensure that all computers can reach a DNS
server for registering and resolving IP addresses. You can either deploy DNS on a VM in the Azure virtual
network or have VMs register their addresses with an on-premises DNS server. Your DNS server must
meet the following requirements:
• Must support dynamic registration of resource records in DNS.
• Must have record scavenging switched off. Because DHCP leases in an Azure virtual network are
infinite, record scavenging can remove records that have not been renewed but still are correct.
• Must have DNS recursion enabled.
• Must be accessible on TCP/UDP port 53 from all clients.
Configuring User Defined Routes

Virtual networks allow you to organize resources
in Azure and enable network communication
between them. Virtual networks are similar to on-
premises networks. You can define the range of
private IP addresses that will be allocated to the
VMs or applications in Azure. You also can
logically divide the network by using subnets, and
isolate particular segments by using network
security groups. However, in virtual networks, you
do not configure the default gateway IP address.
As a result, traffic routing in Azure is managed
differently compared to on-premises networks.
VMs that are configured on the virtual network can communicate between themselves, even if they reside
in different subnets, and can communicate with the public Internet. Azure defines system routes for every
virtual network subnet that you create. Those system route contains the following rules:
• Local virtual network rule. This rule is for communications between VMs in the same virtual network.
• On-premises rule. This rule is created when you configure a site-to-site VPN with VPN gateway, and
route the traffic towards on-premises through the IP address of the VPN gateway.
• Internet rule. This rule is for traffic that is sent to the Internet. It uses fabric infrastructure internet
gateway as the default gateway for traffic that is destined for the Internet.
Packet routing is done based on the routing table that specifies the intended route. Each route is created
from the following information:
• Address prefix. Specifies the destination IP address range in CIDR notation.
• Next hop type. Specifies the next hop where the packet will be sent. Possible destinations are:
o Local. Packet is intended for the local delivery inside the virtual network.
o VPN Gateway. Specifies that traffic should be delivered through the VPN Gateway for either on-
premises connectivity or any form of site-to-site VPN connectivity.
o Internet. Specify the default Internet gateway that is provided by the Azure infrastructure for
traffic going to the Internet.
o Virtual Appliance. Specifies the IP address of a virtual appliance that you can add to virtual
network for different network configurations.
o NULL. Specifies a non-existent destination so that traffic will not be forwarded at all.
• Nexthop value. Applies to the Virtual Appliance next hop type and contains the IP address of Virtual
Appliance, where packets should be forwarded.
Although these routes in most situations simplify the network connectivity process, there might be
requirements to modify default packet flow and configure routing differently. For example, your network
policy might state that all internet traffic should pass through internal systems for auditing and packet
inspection. In such a case, you would need to configure user-defined routes that implement forced
tunneling. Similarly, you might need to implement virtual appliance for packet inspection in Azure.
The Azure Resource Manager allows you to create User Defined Routes that specify the next hop of the
packet, and then assign these routes to specific subnets. You can create User Defined Routes by using the
Azure PowerShell Module, Azure command line interface (Azure CLI), or by using ARM templates.
For example, suppose that you need to inspect all traffic that originates from the subnet named
AdatumSubnet in the virtual network AdatumVnet. You plan to use IP forwarding so that all traffic that
originates from AdatumSubnet is sent to the virtual appliance named FW1. IP Forwarding allows the
Azure virtual switch to forward packet to a VM when the destination of the packet is not the IP address of
that VM. The following procedure describes how to implement this scenario:
1. Start Microsoft Azure PowerShell, and sign in to your subscription:
which you are going to create the virtual network and configure User Defined Routes:
Set-AzureRMContext –SubscriptionName <Name of your subscription>
4. Create a new virtual network named AdatumVnet, and an address space—for example ,
192.168.0.0/16 and store a reference to it a PowerShell variable $vnet:

Add-AzureRmVirtualNetworkSubnetConfig -Name AdatumSubnet -VirtualNetwork $vnet

7. Create a route that will route all the traffic from AdatumSubnet (192.168.1.0/24) to the virtual
appliance named Firewall (192.168.0.10):
$route = New-AzureRmRouteConfig –Name RoutetoVA `

-AddressPrefix 192.168.1.0/24 -NextHopType VirtualAppliance `
-NextHopIpAddress 192.168.0.10
8. Create a route table named Adatum-FW that contains the previously created route:
$routeTable = New-AzureRmRouteTable -ResourceGroupName AdatumRG -Location centralus `

-Name Adatum-FW -Route $route
9. Associate the route table created previously to the AdatumSubnet subnet:
Set-AzureRmVirtualNetworkSubnetConfig -VirtualNetwork $vnet -Name AdatumSubnet `

-AddressPrefix 192.168.1.0/24 -RouteTable $routeTable
10. Set the configuration in the virtual network:
11. Use a variable to store settings for the NIC that is used by the virtual appliance named Firewall. The
name of the NIC for this scenario is NICFW:
$nicfw = Get-AzureRmNetworkInterface -ResourceGroupName AdatumRG -Name NICFW
12. Enable IP forwarding:
$nicfw.EnableIPForwarding = 1
13. Update the NIC settings:
Set-AzureRmNetworkInterface –NetworkInterface $nicfw

Configuring forced tunneling

Many companies implement different polices and
packet inspections for traffic that crosses their
network boundaries. When they extend their
networks in Azure by implementing site-to-site
VPNs, any VMs that are residing in virtual network
have the default route to the Internet via
Microsoft Azure fabric.
Forced tunneling redirects internet-bound traffic

back to the company’s on-premises infrastructure.
With forced tunneling, you can selectively choose
virtual network subnets, from which you traverse
traffic back to your on-premises network and then
force corporate auditing and packet inspection. This selective approach gives organizations flexibility for
workloads that need public internet access, such as web servers, to continue to use direct internet
communications via Microsoft Azure fabric. For other workloads that might impose some security
requirements, you can configure forced tunneling, so that all outbound traffic is redirected back to the
on-premises network by using site-to-site VPN tunneling.
You configure forced tunneling by creating a default route for selected subnets in the virtual network to
send outbound traffic through the virtual network VPN gateway. To configure forced tunneling, you need
to create a routing table by using User Defined Routes, and then configure the virtual network subnet
with that routing table. The User Defined Routes routing table routes the traffic through the dynamic VPN
gateway, which is created for the corresponding site-to-site VPN.
For example, suppose that you plan to use forced tunneling for the traffic that originates from the subnet
named AdatumSubnet in the virtual network AdatumVnet. You plan to create User Defined Routes, and
define that traffic should be routed back to the on-premises network through the VPN gateway. The
following procedure explains the steps to address this desired scenario:
1. Start Microsoft Azure PowerShell and sign in to your subscription:
2. Select the subscription in which you are going to create the virtual network, and configure forced
tunneling:
4. Create a new virtual network named AdatumVnet, and an address space—for example ,
192.168.0.0/16 and store a reference to it a PowerShell variable $vnet:

Add-AzureRmVirtualNetworkSubnetConfig -Name AdatumSubnet -VirtualNetwork $vnet

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

7. Update the configuration of the virtual network:
8. Create the object representing you on-premises VPN gateway and store it in the variable $GW:
$GW = New-AzureRmLocalNetworkGateway -Name "AdatumLocalGW" -ResourceGroupName

"AdatumRG" -Location "centralus" -GatewayIpAddress "111.111.111.111" -AddressPrefix
"10.1.0.0/24"
9. Create a route that will send all the traffic from AdatumSubnet (192.168.1.0/24) through the VNet
gateway:
$route = New-AzureRmRouteConfig -Name DefaultRoute `

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

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

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

-Location "centralUS" -AllocationMethod Dynamic
14. Configure IP configuration for the Gateway Subnet:
$gwsubnet = Get-AzureRmVirtualNetworkSubnetConfig -Name "GatewaySubnet"

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

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

"AdatumRG" -Location "centralus" –VirtualNetworkGateway1 $Gateway1
-LocalNetworkGateway2 $GW -ConnectionType IPsec -SharedKey "preSharedKey"
Configuring network security groups

VMs that you create with the Azure resource
deployment model can have direct connectivity to
the Internet by using a public IP address that is
assigned directly to the VMs. These VMs are
protected from the Internet only with the host
firewall that is configured inside the VMs.
VMs that are created with the Azure classic

deployment model communicate with Internet
resources through the cloud service that is
assigned the public IP address, known as VIP
address. VMs that reside inside the cloud service
share that VIP address, and establish
communications with Internet resources by using endpoints. If you remove the VM endpoints that map
the public port and public IP address of the cloud service with the private port and private IP address of
the VM, the VMs become unreachable from the Internet if using the public IP address.
Network Security Groups provide advanced security protection for the VMs that you create using either
deployment method. They control inbound and outbound traffic passing through a NIC (Resource
Manage deployment model), a VM (classic deployment), or a subnet (both deployment models). NSGs
contain rules that specify whether the traffic is approved or denied. Each rule is based on a source IP
address, a source port, a destination IP address, and a destination port. Based on whether the traffic
matches this combination, it either is allowed or denied. Each rule consists of the following properties:
• Name. This is a unique identifier for the rule.
• Direction. Direction specifies whether the traffic is inbound or outbound.
• Priority. If multiple rules match the traffic, rules with higher priority apply.
• Access. Access specifies whether the traffic is allowed or denied.
• Source IP address prefix. This identifies from where traffic originates. This prefix can be based on a
single IP address, a range of IP addresses in CIDR notation, or the asterisk (*) wildcard character, that
must match all possible IP addresses.
• Source port range. This specifies source ports by using either a single port number from 1-65535, a
range of ports (200-400), or the asterisk (*) wildcard character that denotes all possible ports.
• Destination IP address prefix. This identifies the traffic destination based on a single IP address, a
range of IP addresses in CIDR notation, or the asterisk (*) wildcard character, that must match all
possible IP addresses.
• Destination port range. This specifies destination ports by using either a single port number from 1-
65535, a range of ports (200-400), or the asterisk (*) wildcard character, that denotes all possible
ports.
• Protocol. Protocol specifies a protocol that matches the rule. It can be UDP, TCP or the asterisk (*)
wildcard character *.
There are predefined default rules for inbound and outbound traffic. You cannot delete these rules, but
you can override them, because they have the lowest priority. Default rules allow all inbound and
outbound traffic within a virtual network, allow outbound traffic towards the Internet, and permit inbound
traffic to Azure load balancer. There is also a default rule in both inbound and outbound sets of rules that
denies all network communication with the lowest priority.
When you create a custom rule, you can use default tags in the source and destination address prefix to
specify a predefined category of IP addresses. These default tags are:
• Internet. This tag represents Internet IP addresses.
• Virtual_network. This tag identifies all IP addresses that are defined in the IP range for the virtual
network. It also includes IP address ranges from on-premises networks when they are defined as Local
network to virtual network.
• Azure_loadbalancer. This tag specifies the default Azure load balancer destination.
Planning network security groups

You can design Network Security Groups to isolate virtual networks in security zones, similar to the model
that is used in on-premises infrastructure. You can apply network security groups to subnets so that you
can create protected screened subnets (also called DMZ) that can restrict traffic flow to all the machines
that reside within that subnet. You also can assign network security groups to individual computers in the
Azure classic deployment model, to control traffic that is both destined for, and leaving the VM. In an
Azure Resource Manager deployment, you can assign network security groups to a NIC so that only the
traffic that flows through that NIC is controlled by network security group rules. If the VM has multiple
NICs, network security group rules are not automatically applied to traffic that is designated to other NICs.
Network security groups are resources that are created in a resource group, but can be shared with other
resource groups that exist in your subscription. This means that if you create a network security group, for
example in the TestRG resource group, you can use that network security group for a VM that belong to
other resource group, for example ProductionRG.
Some important things to keep in mind while implementing network security groups include:
• By default you can create 100 NSGs per region per subscription. You can raise this limit to 400 by
contacting Azure support.
• You can apply only one NSG to a VM, subnet, or NIC.
• By default, you can have up to 200 rules in a single NSG. You can raise this limit to 500 by contacting
Azure support.
• You can apply an NSG to multiple resources.

Creating network security groups and configuring rules

You can create network security groups by using the Azure PowerShell module, or by using ARM
templates.
In Azure PowerShell, to create a new NSG named Adatum-RG, you use the command New-
AzureRMNetworkSecurityGroup:
New-AzureRmNetworkSecurityGroup -ResourceGroupName AdatumRG -Location centralus -Name

"Adatum-FrontEnd"
You can use Azure portal to create and configure rules for new and existing network security groups. To
create a custom rule for an existing network security group in the Azure portal, follow the procedure
below:
1. In a web browser, navigate to http://portal.azure.com. If necessary, sign in with your Azure account.
2. Click Browse, and then select Network security groups.
3. From the list in the Network Security Groups blade, select the NSG that you plan to modify.
4. Click either the Inbound or the Outbound rule.
5. In the Inbound Security rules blade, click Add.

6. In the Add inbound security rule blade, configure the following properties, and then click OK:
o Name: Use a descriptive name.
o Priority: Specify a value to identify the priority of the rule.

o Source address prefix: Use either Any, CIDR Block, or Tag as a source IP address range.
o Protocol: Specify either Any, or TCP or UDP protocol.
o Source port range: Specify either a single port or a range of ports to match the rule.
o Destination address prefix: Use either Any, CIDR Block, or Tag as a destination IP address range.
o Destination port range: Specify either a single port or a range of ports to match the rule.
o Action: Specify either allow or deny action for the traffic that matches the properties of the rule.
Demonstration: Configuring network security groups

In this demonstration, you will learn how to create a network security group and associate it with a subnet
of a virtual network.
Demonstration Steps
1. From the taskbar, start Windows PowerShell, and then sign in to your subscription by using the
Login-AzureRMAccount command.
2. Select your subscription by using the Set-AzureRmContext command.
3. Create a variable $vnet that references the virtual network named AdatumDemoVnet in the
AdatumDemoRG resource group that you created in the previous demo.
4. Create a network security group named AdatumDemoRG in the same resource group and location
as the virtual network AdatumDemoVnet by using the New-AzureRmNetworkSecurityGroup
command.
5. In Azure portal, navigate to the AdatumDemoNSG network security group.

6. Add an inbound security rule with the following properties:
o Name: DisableInboundTraffic
o Priority: 500
o Source: Tag
o Source tag: Internet
o Protocol: Any
o Source port range: *
o Destination: Any
o Destination port range: *
o Action: Deny
7. Associate the newly created rule with the AdatumSubnet1 subnet of the AdatumDemoVnet virtual
network.
8. Close all open applications without saving any files.
9. On the taskbar, right-click Windows PowerShell, and then click Run as administrator.
10. In the User Account Control dialog box, click Yes.
Reset-Azure
12. When prompted, sign in by using the Microsoft account associated with your Azure subscription.
13. If you have multiple Azure subscriptions, select the one you want to target with the script.
Note: This script might remove Azure services in your subscription. Therefore, we
recommend that you use an Azure trial pass that was provisioned specifically for this course, and
not your own Azure account.
The script will take 5-10 minutes to reset your Microsoft Azure environment, and ready it for
demos and labs in the next module..
The script removes all storage, virtual machines (VMs), virtual networks and gateways, cloud
services, and resource groups.
Important: The script might not be able to get exclusive access to a storage account to delete it
(you will see an error, if this occurs). If you find objects remaining after the reset script is
complete, you can re-run Reset-Azure script, or use the full Azure Management Portal to
manually delete all the objects in your Azure subscription, with the exception of the default
directory.
Lesson 4
Configuring virtual network connectivity
You can think of Azure as your datacenter in the cloud, or as another branch office. Typically, branch
offices are connected by using VPN connections. In this lesson, you will learn how to establish connectivity
between two or more sites in Azure. You also will learn how to connect from your on-premises computers
to virtual networks.
Lesson Objectives
• Describe the options for intersite connectivity.
• Describe how to configure a point-to-site VPN.
• Describe how to configure site-to-site VPNs.
• Describe how to configure VNet-to-VNet VPNs.

• Explain how to connect IaaS v1 VNets to IaaS v2 VNets.
Intersite connectivity options

By creating a VPN connection to a virtual network,
you allow clients to connect as if the virtual
network resources were on the local network. The
cloud connection thus becomes transparent to the
user. All VPN connections require a virtual
gateway in the virtual network, which routes
traffic to the on-premises computers. The
following VPN connections are available.
Point-to-site
A point-to-site VPN connects a single computer
to a virtual network through a VPN tunnel. You
must configure a certificate to secure this
connection, and then install a client configuration package on the client computer.
Use point-to-site connections when you have a small number of client computers that you want to
connect to Azure virtual network. Remember that computers with a point-to-site VPN can use that
connection from anywhere that they have Internet access. For example, they could connect to the virtual
network from a café with Wi-Fi.
Site-to-site
A site-to-site VPN connects an on-premises TCP/IP network to a virtual network through a VPN tunnel. In
the on-premises network, a VPN device routes traffic to the virtual network. You either can use a
compatible third-party VPN device, or use a server running Windows server with the Routing and Remote
Access service (RRAS) configured. Azure provides scripts that you can use to configure different VPN
devices.
Use site-to-site connection when you have a large number of client computers that are all connected to
an on-premises network. Unlike point-to-site connections, clients can only use site-to-site connections
when they have a direct connection to the on-premises network.
VNet-to-VNet
A VNet-to-VNet VPN connects one Azure virtual network to another. The two virtual networks can be in
different regions or even in different Azure subscriptions. For example, you could use a VNet-to-VNet
VPN to connect to a partner organization’s virtual network, providing the IP address spaces of the two
virtual networks do not overlap.
When you configure a VNet-to-VNet connection, you must specify the IP address spaces in use for private
IP addresses on the opposite virtual networks so that the virtual gateway can route traffic to the correct
location. In the user interface this is referred to as the local network, because the virtual gateway routes
traffic in exactly the same way as it would to an on-premises network. This can be confusing, because in
the opposite virtual network, the first virtual network is referred to as the “local network” as well. Think of
this setting as telling Azure the network you are connecting to is local (not out in the Internet).
IaaS v1 VNet-to-IaaS v2 VNet

Resources that exist in the Azure classic deployment model cannot communicate directly with resources
created in an ARM virtual network. To allow for such communication you can create an IaaS v1 VNet-to-
IaaS v2 VNet connection, which has many similarities to VNet-to-VNet communication. You must carefully
plan IP address spaces so that they are not overlapping. Similar to VNet-to-VNet configuration, you need
to define the local network to be the address space that is used in the other virtual network. Then you
need to create a virtual gateway in both networks so that they can route the traffic between the two
networks.
Multisite
You can create a single VPN that connects multiple on-premises networks to a single virtual network. This
is known as a multisite VPN, which is very similar to a site-to-site VPN. The primary difference is that you
must configure a multisite VPN in the classic deployment model by using a network configuration file. The
Azure portal does not support multisite VPNs at the time of writing this course.
Additional Reading: For more information, refer to Connect multiple on-premises sites to
a virtual network: http://aka.ms/l0dzgr.
ExpressRoute
The ExpressRoute service can provide a private connection from your datacenter to an Azure virtual
network, through a connection service provider. This can improve security and achieve higher bandwidth,
lower latency, and better reliability. Microsoft works with network service providers to build these
connections.
Additional Reading: For more information, refer to ExpressRoute: An overview:

http://aka.ms/Wf6dsv.
When planning and configuring your VPN connections to and from virtual networks, keep the following
facts in mind:
• Azure supports a maximum of 30 VPN tunnels per VPN gateway. Each point-to-site VPN, site-to-site
VPN, or VNet-to-VNet VPN counts as one of those VPN tunnels. A single VPN gateway can support
up to 128 connections from client computers.
• Address spaces must not overlap. Carefully plan the address spaces that you want to use in virtual
networks, and any connected on-premises networks.
• VNet-to-VNet VPNs can connect virtual networks in the same or different Azure subscriptions.
Similarly they can connect virtual networks in the same or different Azure regions.
• Redundant tunnels are not supported.
• Cloud services cannot span virtual networks, even when those virtual networks are connected with a
VPN.
• All VPN tunnels to a virtual network share the available bandwidth on the Azure VPN gateway. This
includes point-to-site VPNs.
• VPN devices must meet certain requirements. These requirements are listed on the Microsoft website,
About VPN devices for site-to-site VPN Gateway connections webpage. On this page you also can
find a list of compatible third-party VPN devices on the same page.
Additional Reading: For more information, refer to About VPN devices for site-to-site VPN
Gateway connections: http://aka.ms/Frtaeb.
Configuring point-to-site VPN connectivity

To set up a point-to-site VPN, you must configure
an IP address space, configure a virtual gateway,
create certificates, and then install a client VPN
package.
Note: At the time of the writing this course,

the Azure portal does not support creation of
point-to-site virtual network.
Creating a point-to-site connection

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

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

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

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


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

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

–PublicIPAddress= $pip
Set-AzureRMVirtualNetwork –VirtualNetwork $vnet.
Create Root and Client certificates

You can use certificates to authenticate clients as they connect to the VPN, and to encrypt the connection
to improve security. You must generate a self-signed root certificate, upload it to the Azure portal,
reference it to generate a client certificate, and then install the client certificate on your computer. To
complete these tasks, use the following steps:
1. For Windows 10 computers you need to install the Windows 10 SDK, and then open the command
prompt in the location where the makecert tool is installed. The default installation location is:
C:\Program Files (x86)\Windows Kits\10\bin\X64.
2. To generate the root certificate, type the following command at the command prompt, and then
press Enter:
makecert -sky exchange -r -n "CN=AdatumRootCertificate" -pe -a sha1 -len 2048 -ss My

"AdatumRootCertificate.cer"
3. In the location, from where you run the makecert tool, locate the AdatumRootCertificate.cer file,
open it in Notepad, copy the entire string, and store it in the variable $RootCerString.
4. To generate the client certificate, type the following command at the command prompt, and then
press Enter:
makecert.exe -n "CN=AdatumClientCertificate" -pe -sky exchange -m 96 -ss My -in

"AdatumRootCertificate" -is my -a sha1
5. To upload the root certificate, type the following command, and then press Enter:
$RootCer =NewAzureRmVpnClientRootCertificate –name AdatumRootCert –PublicCertData

$RootCertString
Configure a virtual gateway

Point-to-site connections require a virtual gateway in the virtual network that routes traffic to client on-
premises computers. You also need to prepare an IP address pool that you need to allocate to the client
that uses the point-to-site VPN connection. In the command below you use the "172.16.201.0/24" IP
address space. To create the virtual gateway, type the following command, and then press Enter:
New-AzureRmVirtualNetworkGateway -Name AdatumGateway -ResourceGroupName AdatumRG -Location

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

To connect to the VPN, a client must use a client configuration package. This package must include the
client certificate that you just created:
1. To retrieve the URL link to download a VPN Client Configuration package, type the following
command, and then press Enter:
Get-AzureRmVpnClientPackage -ResourceGroupName AdatumRG -VirtualNetworkGatewayName

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

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

You can use site-to-site connections for cross-
premises and hybrid configurations between
Azure virtual networks and on-premises networks.
Configuring a Site-to Site connection

The following procedure describes how to
configure a Site-to Site connection for Azure:
Connect to your Azure subscription from

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




Set-AzureRMVirtualNetwork –VirtualNetwork $vnet.
Add a local site

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

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

–Location centralus –AllocationMethod Dynamic
2. Specify a variable for the gateway subnet from the VNet:
$subnet= Get-AzureRmVirtualNetworkSubnetConfig –Name “GatewaySubnet” –virtualnetwork

$vnet
3. Provide the IP configuration required for the VPN gateway:
$ipconfig= New-AzureRmVirtualNetworkGatewayIPConfig –Name GWIPConfig –Subnet $subnet

–PublicIPAddress $pip
Create a virtual gateway

• Create a virtual gateway that will be used for the site-to-site VPN connection, and then store the
value in the variable $gateway. Specify the following values:
o GatewayType: Define the gateway type to be VPN
o VpnType: Configure RouteBased VPN type, or PolicyBased VPN type
$gateway = New-AzureRmVirtualNetworkGateway -Name AdatumGateway -ResourceGroupName

AdatumRG -Location centralus -IpConfigurations $ipconfig -GatewayType Vpn -VpnType
RouteBased
Configure a VPN device

• A Site-to-Site VPN requires an on-premises VPN device, which routes traffic from the on-premises
network to the virtual network, and receives traffic from the virtual gateway. You can use either a
computer running Windows Server with RRAS configured for this device, or use a supported third-
party device. To find the public IP address of your virtual network gateway run the following
command:
Get-AzureRmPublicIpAddress -Name gwpip -ResourceGroupName AdatumRG
Create a VPN connection:

• Create the VPN connection named localtoazure between the on-premises VPN gateway and the
virtual network gateway that you created for your Azure virtual network. You need to provide the
following information:
o The shared key. This key is used to encrypt the VPN and is specified during on-premises VPN
gateway configuration.
New-AzureRmVirtualNetworkGatewayConnection -Name localtoazure -ResourceGroupName

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

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

adatumrg -Debug.
Configuring a VNet-to-VNet VPN

You can use a VNet-to-VNet VPN to connect one
virtual network to another. The connected virtual
networks can be in the same Azure region or in
different regions. They also can be in the same
Azure subscription or in different subscriptions.
The process of configuring a VNet-to-VNet VPN

connection is similar to a site-to-site VPN
connection, with one difference: the other side of
the connection is not an on-premises network, but
another virtual network that resides in Azure.
The following procedure lists the high-level steps

for creating a VNet-to-VNet VPN connection:
1. Connect to your Azure subscription.
2. Create the first virtual network.
3. Request a public IP address, and create the gateway configuration.

4. Create the gateway.
5. Create the second virtual network and its gateway.
6. Connect the gateways.
Some important points to keep in mind before you start creating a VNet-to-VNet VPN connection:
• You must complete almost identical steps at both ends of the VPN because the configuration is
symmetrical.
• IP address space for the virtual networks connected by a VPM Gateway must not overlap.
• Once you create both VPN gateways, you must return to configure the actual IP address of the
opposite end of the connection.
• There is no on-premises network in a VNet-to-VNet connection. For each virtual network, the local
network IP address range refers to the private IP addresses in the opposite virtual network.
Note: You will configure a VNet-to-VNet VPN in the lab and see the procedure in detail.
Here, an overview of the process is provided.
Creating a VNet-to-VNet VPN connection

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

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

Create a virtual network and gateway subnet

New-AzureRmResourceGroup –Name AdatumRG –Location centralus
$vnet = New-AzureRmVirtualNetwork –ResourceGroupName AdatumRG –Name AdatumVnet



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

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

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

$subnet.Id –PublicIPAddressId $pip.Id
Create a virtual gateway

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

AdatumRG -Location centralus -IpConfigurations $ipconfig -GatewayType Vpn -VpnType
RouteBased
Create a second virtual network

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

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

-VirtualNetworkGateway1 $vnetgw1 -VirtualNetworkGateway2 $vnetgw2 -Location centralus
-ConnectionType Vnet2Vnet -SharedKey 'abc123'
New-AzureRmVirtualNetworkGatewayConnection -Name conn2 -ResourceGroupName AdatumRG
-VirtualNetworkGateway1 $vnetgw2 -VirtualNetworkGateway2 $vnetgw1 -Location westus
-ConnectionType Vnet2Vnet -SharedKey 'abc123'
Connecting IaaS v1 virtual networks to IaaS v2 virtual networks
VMs that you create with the Azure classic

deployment model cannot communicate directly
with VMs that you create with the Azure Resource
Manager deployment model. To allow this type of
communication, you must create a VPN
connection between the classic virtual network
and the ARM virtual network.
Connecting a classic virtual network and

an ARM virtual network
The following procedure lists the steps to create
an IaaS v2 virtual network, an IaaS v1 virtual
network, and a VPN connection between them:
Create a virtual network by using Resource Manager

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

1. Sign in to the Azure portal.
2. In the navigation menu on the left, click New, select Networking, and then click Virtual Network.
3. In the Virtual Network blade, select Classic deployment model, and then click Create.
4. In the Create virtual network blade, in the Name text box, type a descriptive name for the virtual
network, for example VNetClassic.
5. In the Address space drop-down list box, select the IP address range by using CIDR notation, for
example 172.16.0.0/16.
7. In the Subnet address range text box, choose the IP address range for the subnet using CIDR
notation.
8. In the Subscription drop-down list, select the Azure subscription in which you want to create a
virtual network.
9. In the Resource group section, either create a new resource group or select an existing one.
10. In the Location drop-down list box, select a location near your users, and then click Create.
Connect the classic and the ARM virtual networks:

1. To connect two virtual networks that use different deployment models, add the IP address range of
one virtual network to the local network for the other virtual network. You need do this for both
virtual networks.
2. Create VPN gateways for both virtual networks.
3. Configure both gateways. For an ARM gateway configuration, follow the procedure described in the
earlier topic, Configuring VNet-to-VNet VPN connection, For classic virtual network, the procedure
for creating a VPN gateway is explained in the next Lesson, Overview of Azure Networking in IaaS v1.
4. Create a pair of PowerShell variables representing the IaaS v1 VNet gateway and the IaaS v2 VNet
gateway (we will call them here $vnet01gateway and $vnet02gateway, respectively). To create a
connection between the gateways use the following command:
New-AzureRmVirtualNetworkGatewayConnection -Name arm-asm-s2s-connection `

-ResourceGroupName AdatumRG -Location centralus -VirtualNetworkGateway1
$vnet01gateway `
-LocalNetworkGateway2 $vnet02gateway -ConnectionType IPsec `
-RoutingWeight 10 -SharedKey 'abc123'
Lesson 5
Overview of Azure networking in IaaS v1
Azure networking is a fundamental component of an Azure solution. Many organizations have already
built their solutions by using the Azure classic deployment model, because that was the only one that
existed when Azure services first became available. In this lesson, you will learn about the functionality of
virtual networks created with the Azure classic deployment model, and identify how they differ from
virtual networks created by using ARM templates.
Lesson Objectives
• Identify the functionality of IaaS v1 virtual networks.
• Explain how to connect to virtual networks in IaaS v1.
• Describe how to implement virtual networks in IaaS v1.
Overview of IaaS v1 virtual networks

The Azure classic deployment model has an
entirely different networking stack from the ARM
deployment model. You can create VMs in Azure
without using virtual networks. However, you
must place each VM in an IaaS cloud service. You
can create each VM in a separate cloud service, or
you can add two or more VMs to a single cloud
service. VMs in the same IaaS cloud service can
communicate directly, but you have no control
over their IP addresses or DNS configuration. VMs
in different cloud services that are not part of a
virtual network communicate through cloud
service endpoints that have specific port numbers.
Virtual networks for cloud services and VMs

Once you have created a virtual network, you can place new VMs and PaaS cloud services into the new
virtual network. VMs and cloud services within the same virtual network can communicate directly without
going through an endpoint.
IP addressing in virtual networks

VMs and PaaS cloud service roles in a single virtual network require a unique IP address in the same way
as clients in an on-premises subnet do. This enables these VMs and cloud service roles to communicate
with each other. There are three types of IP addresses that are used in an Azure virtual network:
• DIPs. A DIP is a dynamic internal IP address. This address is used by VMs in the virtual network to
communicate with other VMs in the same virtual network. When you have connected a VPN to an
Azure virtual network, on-premises clients communicate with VMs in a virtual network by using DIPs.
• VIP addresses. A VIP address is a virtual IP address that is assigned to a cloud service (either an IaaS
cloud service or a PaaS cloud service). This address is used by external clients to communicate with
the cloud service and its VMs. All VMs within a single cloud service have the same VIP address.
• Public instance-level IP addresses (PIP). A PIP address is associated directly with the VM, and enables
direct Internet-based communication without relying on cloud service endpoints.
Azure assigns DIPs by using the DHCP protocol. DHCP leases are infinite in duration, thereby making the
IP addresses stable. However, in some circumstances, such as when a VM has been placed into the
Stopped (Deallocated) state, a DIP could change.
If you are using a VPN to connect on-premises computers to the virtual network, you must ensure that
the on-premises IP address and the virtual network DIPs do not conflict.
You can ensure that a VM always has the same DIP by setting a static internal IP address (also known as a
persistent private IP address). Start by verifying that the IP address that you want to reserve is not already
in use, then use the Set-AzureStaticVNetIP cmdlet as in the following example:
Setting a Static Internal IP Address

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

Get-AzureVM -ServiceName AdatumWebFrontEnd -Name WebVM1 | Set-AzureStaticVNetIP
-IPAddress 192.168.1.10 | Update-AzureVM
Note: When you want to assign a static IP address to on-premises computers, you can use
the Network Interface dialog box within the Windows operating system. You must not use this
method for VMs within Azure however, because it will result in dropped connections and
connectivity failures. Instead, use the Azure portal or the Set-AzureStaticVNetIP cmdlet as
described above.
Similarly, you also can ensure that the VIP address for a cloud service and the VMs it contains never
changes, by using a reserved IP. To do this, create a reserved IP with the New-AzureReservedIP cmdlet,
and then pass it to a new VM as you create it:
Adding a Reserved IP for a New VM

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

AzureProvisioningConfig -Windows -AdminUsername Administrator -Password Pa$$w0rd | New-
AzureVM -ServiceName "WebFrontEnd" -ReservedIPName $ReservedIP -Location "West US"
Most of the time, VIP addresses are the only external IP addresses that you need to assign. You assign a
VIP address to an IaaS cloud service and use endpoints to specify one or more VMs that receive incoming
traffic to the VIP address. Alternatively, you can assign a VIP address to a PaaS cloud service, and then use
endpoints to specify the role in the PaaS cloud service that receives incoming traffic.
However, in some cases you might want to enable external clients to communicate directly with a specific
VM in a cloud service through a direct IP address without specifying a port number. For example, if you
are using File Transfer Protocol (FTP) in passive mode, the client negotiates the port number to use for
transferring files. In such cases, you should assign an instance-level PIP to the VM.
In this example, the script assigns a PIP to an Azure IaaS v1 VM.
Assigning an Instance-Level PIP to a VM

Get-AzureVM -ServiceName FTPService -Name FTPVM1 | Set-AzurePublicIP -PublicIPName ftpip
| Update-AzureVM
You also can configure multiple NICs for Azure VMs. In this case, each NIC receives a separate DIP and
you can utilize the NICs to isolate communication.
Additional Reading: For more information, refer to Create a VM with multiple NICs:
http://aka.ms/Oqb3ci.
DNS enables clients to resolve user-friendly FQDNs, such as www.adatum.com, to IP addresses. Azure
provides a DNS to support many name resolution scenarios. However, in some cases you might need to
configure an external DNS system to resolve IP addresses with an Azure virtual network.
For example, a VM in an IaaS cloud service can use the Azure internal DNS system to resolve the DIP of
any other VM in the same service. However, in a hybrid scenario where your on-premises network is
connected to and Azure virtual network through a VPN, an on-premises computer cannot resolve the DIP
of a VM in an Azure virtual network until you configured the DNS servers with a record for the VM.
Azure load balancer and internal load balancer

External clients use a VIP address to communicate with a VM. This VIP address is associated with an IaaS
v1 cloud service that might be in an Azure virtual network. You define endpoints on the cloud service to
enable external clients to connect to specific port on a specific VMs within the cloud service. By default, an
endpoint is associated with a single VM.
You can use a load-balanced set of VMs to enable port-based traffic distribution between VMs in a single
cloud service. In this configuration, multiple VMs share a single endpoint. The Azure load balancer
distributes requests automatically across those VMs as they arrive at the endpoint.
Now consider a scenario where one VM in a virtual network communicates with other VMs in the same
virtual network. For example, a web server might want to access a group of middle-tier servers. You can
use the Azure load balancer for this load distribution, if you specify the cloud service and endpoint.
Alternatively, you can configure the internal load balancer (ILB) for such distribution. The internal load
balancer enables you to load-balance traffic between VMs in the same IaaS cloud service, without routing
that traffic through an cloud service Internet-based endpoint. ILB uses a private IP address in your virtual
network as input endpoint, and thus do not directly expose resources to the Internet endpoint.
Traffic Manager
Traffic Manager is another load-balancing solution included within Azure that can load balance between
endpoints that are located in anywhere. The Azure classic deployment model supports the same Traffic
Manager functionalities, as does the ARM model. You will learn more on this in Module, “Implementing
App Services.”
Connecting to virtual networks in IaaS v1

The Azure classic deployment model provides the
same cross-premises network connectivity option
as the ARM model. The following list are the
connectivity options that you can use:
• Point-to-site
• site-to-site
• VNet-to-VNet
• Multisite
• ExpressRoute
Creating a point-to-site VPN connection

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

When creating a point-to-site VPN connection, start by specifying a range of IP addresses that will be
used for clients that connect to the VPN. The range must not overlap the ranges used for internal DIPs in
the virtual network or any other range used for site-to-site or VNet-to-VNet connections. The Azure
classic portal displays a warning if there is such an overlap:
1. In the Azure classic portal, in the navigation on the left, click NETWORKS.
2. In the list of available virtual networks, click the name of the virtual network that you want to
configure.
3. Click the CONFIGURE tab.
4. Under point-to-site connectivity, select Configure point-to-site connectivity.
5. In the address space table, select the starting IP address and a CIDR notation subnet mask to specify
and address range. All clients that connect to this point-to-site VPN will receive an IP address from
this range.
6. In the toolbar at the bottom, click SAVE, and then click YES.
Configure a virtual gateway

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

Create root and client certificates

Certificates are used to authenticate clients as they connect to the VPN and to encrypt the connection to
enhance security. You must generate a self-signed root certificate, upload it to the portal, reference it to
generate a client certificate, and then install the client certificate on your computer. To complete these
tasks, perform the following steps:
1. Start a command prompt as administrator and use cd commands to navigate to the Visual Studio
Tools folder.
2. Type the following command at the command prompt, and then press Enter:
makecert -sky exchange -r -n "CN=AdatumRootCertificate" -pe -a sha1 -len 2048 -ss My

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

Create and Install the VPN client configuration package

To connect to the VPN, a client must use a client configuration package. This package must include the
client certificate that you just created:
1. In the classic portal, click the DASHBOARD tab for the virtual network.
2. Under quick glance, click the VPN package for the appropriate client operating system.
3. Save the configuration .exe file.

4. On the client computer, double-click the configuration file that you just downloaded. If the User
Control dialog box displays, click Yes.
Connect to the VPN

Now that you have installed both the client certificate and the VPN client configuration package, you can
connect to the virtual network.
1. Navigate to the list of available VPN connections, and then locate the VPN connection that you have
created. The name of the VPN connection will be the same as the name of the virtual network in
Azure.
2. Right-click the connection, and then click Connect.
3. Click Continue, and then click Connect.
Note: The logic and the primary functionality of the Classic configuration is the same as
that of ARM with cross-premises network configurations. However, the Azure classic deployment
model uses a different set of APIs and protocols, so the procedure for creating the cross-
connectivity differs from the ARM mode.
Configuring a new virtual network and a site-to-site VPN

To configure a new virtual network and a site-to-site VPN, follow these steps:
1. In the classic portal, create a new virtual network.
2. On the Virtual Network Details page, specify the following values:
o Name. Choose a descriptive, unique name.
o Location. Choose the Azure region that is closest to your user base.
3. On the DNS Servers and VPN Connectivity page, specify the following values:
o DNS Servers. Specify the DNS server name and IP address that VMs in the Virtual Network will
use for name resolution.
o Configure Site-to-Site VPN. Ensure that this is selected.
o Local Network. Select or create a local network.

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

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

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

To create a virtual network in IaaS v1, you either
can use the classic or Azure portal, or upload a
network configuration file. A network configuration
file is an XML file with a specific schema.
To create a cloud-only virtual network in the

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

Networks.
2. In the toolbar at the bottom, click New, and
then click Custom Create.
3. In the Name text box, type a descriptive name for the virtual network.
4. In the Location drop-down list box, select a location near your users, and then click the Next arrow
icon.
5. Under DNS SERVERS, type the name and IP address of the DNS server that VMs in the virtual
network will use. As this is a cloud-only virtual network, you might be able to use Azure internal name
resolution and leave this value blank.
6. Click the Next arrow icon.

7. On the Virtual Network Address Spaces page, add the private address spaces and subnets that you
have planned, and then click Complete.
The Azure virtual network configuration is defined in an XML file called a network configuration file. The
network configuration file can include the following settings:
• The name and location of the virtual network
• DNS servers for the virtual network

• Private IP addresses spaces for DIPs in the virtual network
• Subnets within the private address spaces
• The IP address of the virtual gateway that connects to a VPN

The following example is of a complete XML network configuration file for a virtual network with DNS
servers:
Sample Network Configuration File

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

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

Set-AzureVNetConfig -ConfigurationPath C:\configs\UpdatedConfig.xml
Lab B: Configuring connectivity between IaaS v1 and

IaaS v2
Scenario
Now that A. Datum has deployed an IaaS v2 VNet, the company wants to be able to provide direct
connectivity to the IaaS v1 VMs on the existing IaaS v1 VNet. To allow for direct communication between
VMs on both virtual networks, you need to implement VNet-to-VNet connection between them. You will
accomplish this by modifying and running an Azure PowerShell script. You also want to implement a
point-to-site VPN, so that you can connect from your administrative computer.
Objectives
After completing this lab, you should be able:
• Connect Azure virtual networks using a VNet-to-VNet VPN.
• Configure and test a point-to-site VPN.

• Validate virtual network connectivity using Azure-based and VM-based tools.
Lab Setup
User name: Student
Password: Pa$$w0rd
Before you begin this lab, ensure that you have completed the first lab in this module: Creating virtual
networks.
Exercise 1: Using a PowerShell script to connect IaaS v1 VNet and IaaS v2

VNet
Scenario
A. Datum now wishes to connect the A. Datum HQ and branch virtual networks by using a VPN.
1. Configure Resource Manager virtual network.
2. Configure classic virtual network.
 Task 1: Configure Resource Manager virtual network

1. On MIA-CL1, launch Internet Explorer and sign in to the classic Azure portal using an account that is
either a Service Admin or a co-admin of your Azure subscription.
2. From the navigation bar on the left hand side, select networks, and then click ADATUM-BRANCH-
VNET.
3. On the adatum-branch-vnet page, click DASHBOARD.
4. Ensure that the provisioning of the new virtual gateway that you started in the first lab of this module
has been completed. If not, wait until the provisioning is completed.
5. On MIA-CL1, from the Azure PowerShell window, first review and then run
D:\Labfiles\Lab02\Starter\ ConfigureARMGateway.ps1.
6. When prompted to sign-in (twice), use an account that is either a Service Admin or a co-admin of
your Azure subscription.
7. Occasionally monitor the execution status.
Note: The script might take 20-25 minutes to complete. You do not have to wait for the
script to finish. You can proceed with second task of this exercise and with Exercise 2 from this
lab.
 Task 2: Configure classic virtual network

1. On MIA-CL1, launch Internet Explorer and browse to the Azure Portal.
2. If prompted, sign in to your Azure subscription when prompted with an account that is a Service
admin or a co-admin of your subscription.
3. In the Azure portal, navigate to the list of Virtual networks.
4. In the Virtual networks blade, click HQ.
5. In the HQ blade, in the Connected devices section, take the note of the value in the IP ADDRESS
column for gatewayARM.
6. On MIA-CL1, launch File Explorer and browse to the D:\Configfiles\Lab02 folder.

7. Open the NetworkConfig.xml file by using Notepad.
8. In Notepad, under the LocalNetworkSite section, modify the value of <VPNGatewayAddress>

(which is at this point set to 1.1.1.1) by replacing 1.1.1.1 with the value of the IP address that you
recorded in step 5, save the changes to NetworkConfig.xml, and then close the file.
9. On MIA-CL1, launch Windows PowerShell as Administrator.
10. At the Windows PowerShell prompt, sign into your Azure subscription by running:
Add-AzureAccount
11. If you have multiple subscriptions, to select the target subscription, type the following commands,
and then press Enter after each (replace ‘Name of your subscription’ with the actual name of your
subscription and make sure to enclose the name of your subscription in single quotes):
Get-AzureSubscription
Set-AzureSubsciption –SubscriptionName ‘Name of your subscription’
12. Update the network configuration by running the following command at the Windows PowerShell
command prompt:
Set-AzureVNetConfig -ConfigurationPath D:\Configfiles\Lab02\NetworkConfig.xml
13. Set the IPSec shared key for the classic VNet gateway by running the following command at the
Windows PowerShell command prompt:
Set-AzureVNetGatewayKey –VnetName Adatum-Branch-Vnet –LocalNetworkSiteName HQ

–SharedKey 12345
14. Wait for the command to complete and display the StatusCode OK.
15. Open Internet Explorer and browse to the Azure classic portal. If prompted, sign in by using the
Microsoft account that is either the Service Admin or a co-Admin of your subscription.
16. From the DASHBOARD page of the ADATUM-BRANCH-VNET, verify that this network is connected
to the HQ virtual network. You might need to click CONNECT in the menu bar or refresh the Internet
Explorer page.
17. Leave the Internet Explorer window open.
Results: After completing this exercise, you should have connected the A. Datum HQ and branch virtual
networks, and deployed dynamic routing gateways for each virtual network.
Exercise 2: Configuring a point-to-site VPN

Scenario
A. Datum now wants to implement secure communications from on-premises resources to Azure.
Management wishes to start by configuring and testing a point-to-site VPN connection to a virtual
network in Azure.
1. Configure a VPN from a client to the headquarters virtual network.
2. Connect to the HQ virtual network.
 Task 1: Configure a VPN from a client to the headquarters virtual network

1. In the Azure classic portal, navigate to the CONFIGURE tab of the ADATUM-BRANCH-VNET virtual
network.
2. On the CONFIGURE tab, select Configure point-to-site connectivity, set the address space to
172.16.0.0/24 and save the change.
3. Open a Command Prompt window with elevated privileges, and navigate to C:\Program Files (x86)
\Windows Kits\10\bin\x64.
makecert -sk exchange -r -n "CN=AdatumRootCertificate" -pe -a sha1 -len 2048 -ss My

5. Switch back to Internet Explorer.
6. From the adatum-branch-vnet page, upload the root certificate.
7. Switch back to the Command Prompt window, and type the following command:
makecert.exe -n "CN=AdatumClientCertificate" -pe -sk exchange -m 96 -ss My -in

9. Click the cogwheel in the upper right corner of the Internet Explorer window, click Internet Options,
and then on the Content tab, click Certificates.
10. Verify that the AdatumClientCertificate and AdatumRootCertificate display in the Personal store.
11. Close Certificates, and close Internet Options.

 Task 2: Connect to the HQ virtual network

1. Configure a VPN client by downloading the 64-bit Client VPN Package from the Azure classic portal
and installing it on the local client.
2. From the local client, connect by using the newly configured VPN connection, and verify the resulting
IP configuration by examining the output of ipconfig/all.
3. Verify the VPN connection by initiating an RDP session to the private IP address of ClassicSrv1 Azure
virtual machine.
Note: Note that you could potentially also test connectivity to a file share on ClassicSrv1
Azure virtual machine or ping it by its IP address, however, that would require modifying
Windows Firewall settings on ClassicSrv1 in order to allow File and Printer Sharing traffic.
4. Close the RDP session and disconnect the VPN connection.
Results: After completing this exercise, you should have configured and tested a point-to-site VPN
connection.
Exercise 3: Validating virtual network connectivity

Scenario
A. Datum now wants to test the new Azure networking configuration, and validate the connectivity
between the A. Datum headquarters and the branch virtual network.
Important: Even if you do not complete this exercise, you must ensure that you complete
the Reset the Environment task. This task resets your Azure subscription in preparation for later
labs and ensures that no unnecessary costs accrue.
1. Connect to the A. Datum VMs.
2. Test TCP/IP connectivity between the sites.
 Task 1: Connect to the A. Datum VMs

1. Connect to ClassicSrv1 via an Remote Desktop Protocol (RDP) session from the Azure classic portal.
2. Sign in by using the following credentials:
o User name: Student

o Password: Pa$$w0rd123
3. Minimize the ClassicSrv1 RDP session.
4. Connect to ARMSrv2 via an RDP session from the Azure portal.

5. Sign in by using the following credentials:
 Task 2: Test TCP/IP connectivity between the sites

1. From the ARMSrv2 RDP session, if prompted whether to enable network discovery, click No.
2. Turn Windows Firewall off for the Public profile.
3. Switch to the ClassicSrv1 RDP session.
4. Turn Windows Firewall off for the Public profile.
5. From the ClassicSrv1 RDP session, ping ARMSrv2 (10.0.2.4) by its IP address and verify that you are
receiving a response.

Reset-Azure
The script will take 5-10 minutes to reset your Microsoft Azure environment, ready for the next
lab.
The script removes all storage, VMs, virtual networks and gateways, cloud services, and resource
groups.
directory.
Results: After completing this exercise, you should have verified that VMs can communicate between the
virtual networks.
Question: What are the key steps for configuring a point-to-site VPN?
Question: How can you enable communications between VMs that are created with the
Azure classic deployment model and VMs that are created with the ARM model?

Review Question
Question: What are the considerations for choosing a name resolution solution for an Azure
virtual network–based deployment?
Best Practices
1. Always document any network changes, such as modifying values of a DNS server.
2. Use ARM templates for fast and simple virtual network provisioning.
3. Test complex virtual network configurations before you provision production services that will run in
that virtual network.
4. Use your own DNS server configuration for virtual network cross-premises connections.
5. Use virtual network to provide enhanced security and Isolation for services that reside in Azure.
Common Issues and Troubleshooting Tips

Common Issue Troubleshooting Tip
Typical issues that can include:

• Site-to-site VPN tunnel failed
• Wrong virtual network configuration
3-1
Module 3
Implementing virtual machines
Contents:
Module Overview 3-1
Lesson 2: Planning for Azure Virtual Machines 3-7
Lesson 3: Deploying IaaS v2 virtual machines 3-15
Lab A: Creating IaaS v2 virtual machines in Azure 3-22
Lesson 4: Authoring Azure Resource Manager templates 3-25

Lab B: Deploying IaaS v2 virtual machines by using Azure Resource Manager
templates 3-37
Module Overview
Virtual machines are the most flexible resources available for implementing a Microsoft Azure-based
solution for your organization. You can use Azure Virtual Machines to host customized workloads and
applications, implement network-infrastructure roles, or extend your on-premises services into the cloud.
This module introduces the fundamentals of Azure Virtual Machines, and discusses the different ways in
which you can deploy and manage them.
Objectives
• Explain Infrastructure as a Service (IaaS) version 2 (v2) virtual machines.
• Plan for Azure Virtual Machines.
• Deploy IaaS v2 virtual machines.
• Author Azure Resource Manager templates.
• Explain IaaS version 1 (v1) virtual machines.

3-2 Implementing virtual machines
Lesson 1
Overview of IaaS v2 virtual machines
The Azure Resource Manager implementation of virtual machines, virtual networks, and storage offers
a range of new capabilities. When you implement an IaaS v2 infrastructure by using Azure Resource
Manager, it provides you with a more robust virtual-machine deployment and administration. This lesson
explains IaaS v2 as it relates to virtual machines, and it identifies the differences between IaaS v1 and
IaaS v2.
Lesson Objectives
• Describe the IaaS v2 virtual machines.
• Identify the differences between IaaS v1 and IaaS v2 virtual machines.

Perform the following tasks to prepare the demonstration and lab environment:
1. Launch Windows PowerShell as an administrator.

2. Run the Setup-Azure command.
3. Specify the module number, and then confirm your selection.
Important: The scripts that this course utilizes might delete objects in your Azure
subscription. Therefore, we recommend that you use a separate Azure subscription for this
course. Also, to avoid potential confusion, you should use a dedicated Microsoft account that
has not been associated with any other Azure subscription.
The demonstrations and labs in this course use custom Windows PowerShell modules, including
Setup-Azure to prepare the environment, and Reset-Azure to perform clean-up tasks afterwards.
For this module, Setup-Azure removes any cached Azure subscription and account information from
the Azure PowerShell session.
Before you start, your instructor will decide which Azure region is closest to your classroom location. You
will need this information during the lab setup and the lab.
Start the MSL-TMG and 20533C-MIA-CL1 virtual machines, and then sign in to MIA-CL1 as Student with
the password Pa$$w0rd. You should have provisioned a Microsoft Azure subscription before the lab.
Demonstration Steps
1. Launch Windows PowerShell with Administrator privileges.
2. At the Windows PowerShell prompt, type the following command, and then press Enter:
Setup-Azure
3. At the prompt, type the module number, and then press Enter.
6. If you have multiple Azure subscriptions, select the one you want to use for this module.
7. When prompted, provide the number corresponding to the Azure region that you want to use for the
Azure services that this script creates and then press Enter. The script will take about a minute to
complete.
8. After the script completes, close the Windows PowerShell command prompt.
What are IaaS v2 virtual machines?

The Azure Resource Manager implementation
of Azure IaaS includes compute, network, and
storage capabilities that provide a unique way
to administer IaaS resources within Microsoft
Azure. You can implement this new version of
IaaS (IaaS v2) by creating IaaS v2 virtual machines
using several methods: the Azure portal, Azure
Resource Manager templates, Azure command-
line interface (Azure CLI), and the Azure Resource
Manager cmdlets in Azure PowerShell.
IaaS v2 allows you to integrate compute, storage,

and network resources under Azure Resource
Manager. You can declare and define these resources individually, or as part of a larger solution.
With IaaS v2 virtual machines, you can:
• Attach storage and network resources to a virtual machine, without using Azure Cloud Services.
• Create orchestrated deployments with templates and Virtual Machines Extensions (VM Extensions),
including Custom Scripts, Desired State Configuration (DSC), Chef, and Puppet.
• Define tags that you can use for virtual-machine administration and reporting activities.
• Implement role-based access control (RBAC) for fine-grained control over access to virtual-machine
resources and their administration.
Using templates
Templates can incorporate a wide set of Azure services in addition to IaaS resources, including Web apps
and SQL databases. When you use an Azure Resource Manager template, you can define several resources
and their relationship, and deploy that group of resources automatically with the template. You will learn
more about how to create and implement templates later in this module.
Comparing IaaS v1 and IaaS v2 virtual machines
In comparison to IaaS v1 virtual machines created

under the classic management model (formerly
known as Azure Service Management), the IaaS v2
capabilities under Azure Resource Manager
provide a significant change to implementation
and management of virtual machines and their
associated infrastructure. The following table
summarizes the management model of IaaS v1
and IaaS v2 machines.
There are several API enhancements in Azure

Resource Manager that provide significant
performance and functionality enhancements
over the classic model, including:
• Support for large scale and parallel deployment of virtual machines.
• Support for up to three fault domains in availability sets. A fault domain is related directly to a set of
hardware within an Azure datacenter. Each fault domain has independent hardware--essentially, a
separate rack--so that you can host virtual machines across multiple racks, eliminating single points
of failure for a virtual machine.
• Changes to the Custom script extension that allow you to specify scripts from any publicly accessible
URL.
• Integration of the Azure Key Vault with virtual machines to store sensitive data and private
deployment information such as passwords.
• Exposure of network APIs that enable independent creation and assignment of network resources
such as network interfaces, load balancers, and virtual networks. These resources are not dependent
on a virtual machine, and you can reuse them in the deployment process for other virtual machines or
solutions.
IaaS v2 also introduces conceptual differences in the general IaaS model that change how you create and
manage IaaS resources. The following table identifies the primary differences between the Azure Service
Management model and the Azure Resource Manager model.
Item Azure Service Management Azure Resource Manager
Management Azure Service Management Azure Resource Manager enables you to

model provides the application treat virtual-machine resources as
programming interfaces (APIs) independent objects that you can attach to
that enable virtual-machine other IaaS objects, such as a virtual-network
infrastructure in the classic IaaS v1 adapter that you attach to a virtual
model. The IaaS v1 model uses the machine. You can manage these resources
Azure Cloud Services as a individually, or as logical units, in resource
container for virtual-machine groups. Resource groups are the primary
resources. You must attach a logical grouping unit used for both the
virtual machine and its resources initial implementation and management of
to a Cloud Service in Microsoft a group of Azure resources.
Azure, and the Cloud Service
container is the primary
management point.
Azure Cloud Cloud Service is a mandatory Cloud Service does not exist.
Services for container for virtual machines and
virtual associated objects.
machines
Availability You can achieve high availability Availability sets also are available in Azure
sets by assigning an arbitrary Resource Manager. The maximum number
availability set to a virtual of fault domains that you can have is three.
machine. Virtual machines that
you assign to the same availability
set exist in different fault domains,
and the maximum number of fault
domains that you can have is two.
Affinity You have the option of using Affinity groups do not exist.
groups affinity groups when defining
virtual networks.
Load The Cloud Service object acts as a The load balancer is an independent
balancing load balancer for IaaS resources resource. You can assign a network adapter
within Azure Cloud Services. that is attached to a virtual machine to a
load balancer.
Virtual IP The platform automatically assigns Public IP addresses can be static or

address (VIP) a VIP to the Cloud Service upon its dynamic. You have the option of assigning
creation. This address is associated a public IP to a network adapter or a load
with the Cloud Service load balancer.
balancer.
Reserved IP You can reserve IP addresses in Static mode public IP addresses provide the
address Azure, and then associate it with a same capability as reserved IP addresses.
Cloud Service to ensure a
consistent IP address.
Public IP You can assign public IP addresses You can assign public IP addresses to a
address per to a virtual machine directly. network interface, which then can be
virtual assigned to a virtual machine.
machine
Endpoints Virtual machines are exposed to You can access virtual machines for
external network connectivity by management by using the public IP address
configuring input endpoints for for the virtual machine. You can also expose
the Cloud Service to which the virtual machines to external network
virtual machines belong. connectivity by configuring inbound
network address translation (NAT) rules on
a connected load balancer.
DNS name You assign a Cloud Service a You can assign DNS names to public IP
Domain Name System (DNS) name addresses by assigning a domain label. The
based on the name of the Cloud fully qualified domain name (FQDN)
Service, such as: includes the Azure region, such as:
adatumdev.cloudapp.net adatumvm1.eastus.cloudapp.azure.com.
Network You define the primary and Network interface is an independent

interfaces secondary network interfaces resource that is persistent in the Azure
within the configuration of a environment. You can attach it to, and
virtual machine. detach it from, virtual machines without
losing its identity and configuration state.
Its lifecycle might not depend on the
lifecycle of a virtual machine.
Creation and You can use the Classic Portal, the Use the Azure portal, Azure Resource
management Azure Service Management Manager templates, the Azure Resource
cmdlets in Azure PowerShell, Manager cmdlets in Azure PowerShell, the
Azure CLI, or the Azure APIs. Azure CLI, or the Azure APIs.
Question: What are the primary differences between IaaS v2 and IaaS v1 virtual machines?
Lesson 2
Planning for Azure Virtual Machines
You can implement Azure Virtual Machines for several different reasons. You might be implementing a
new cloud-based service or application, moving an existing virtualized infrastructure to Azure, or
extending the scope of your on-premises network by using Azure Virtual Machines. This lesson introduces
you to the key considerations for implementing Azure Virtual Machines, and it describes the methods to
evaluate and migrate existing workloads to Azure.
Lesson Objectives
• Identify the workloads for Azure Virtual Machines.
• Describe the considerations for virtual machine sizing.
• Explain how to migrate workloads to Azure.

• Explain how to evaluate the use of Azure containers.
Identifying workloads for Azure Virtual Machines

Virtual machines can provide a wide variety of
purposes and functionality in Azure. However,
while some workloads are suitable for deploying
to virtual machines in Azure, others are not and
can be more challenging to deploy.
Suitable workloads for virtual machines

in an Azure IaaS environment
Certain types of workloads are a better fit for
hosting in an Azure IaaS environment, such as:
• Highly available service workloads, such as

commercial online stores.
• Periodic workloads, such as:
o Complex data analysis of sales figures that an organization needs to run at the end of each
month.
o Seasonal marketing campaigns on an organization’s website.

o Annual retail sales spurts that may occur during festive holidays.
• Unpredictable growth workloads, such as those experienced by small, but rapidly expanding,
organizations, or by short-term increased sales of “fad” products.
• Spiking workloads, such as those experienced by sites that provide news services or organizations that
perform end-of-day reporting to a head office.
• Steady workload scenarios where organizations simply want to offload their infrastructure to the
cloud.
When you plan virtual-machine workloads for Azure IaaS, you should remember that not every
application or service is a suitable fit for the cloud.
Unsuitable workloads for virtual machines in an Azure IaaS environment

Some workload scenarios do not suit the elasticity and flexibility of an Azure IaaS environment, such as:
• Low-volume or limited-growth workloads, in which an organization might run the service or

application on commodity hardware on-premises, which is less expensive than to run it in the cloud.
• Regulated environment workloads where an organization or local government might regulate the
type of data that it can host in the cloud. However, these cases might be suitable candidates for a
hybrid solution, in which an organization hosts some highly available data in Azure, and then keeps
more sensitive, regulated data on-premises.
IaaS virtual machines vs. PaaS solutions

It is important to evaluate Platform as a Service (PaaS) solutions that you could use in place of some server
roles and services that would run in an Azure virtual machine. For example, you could replace a Windows
Server 2012 R2 virtual machine that is running Internet Information Services (IIS) to provide a web page
with the Azure Web App service. This requires less administration and maintenance, and provides a higher
default level of availability and scalability. The same considerations are true for SQL Server versus Azure
SQL Database; an Active Directory Domain Services (AD DS) domain controller versus Azure Active
Directory Domain Services; and a DNS server versus Azure DNS.
Software support for Azure IaaS virtual machines

You must ensure all Microsoft software that you install in the Azure virtual-machine environment have
proper licenses. By default, Azure Virtual Machines include a license that allows you to use Windows
Server in the Azure environment. Additionally, certain Azure virtual-machine images might include
licenses for additional Microsoft software, on a per-hour or evaluation basis. You must obtain licenses for
other software separately.
A wide range of Microsoft server software is supported in an Azure IaaS virtual machine environment,
including:
• Microsoft Forefront Identity Manager 2010 R2 Service Pack 1 (SP1) and newer versions
• Microsoft SharePoint Server 2010 and newer versions

• Microsoft SQL Server 2008 (64-bit) and newer versions
• Microsoft System Center 2012 SP1 and newer versions

The following table lists the roles that are supported currently in Windows virtual machines and the roles
that are not.
Supported Windows Server roles Unsupported server roles
• AD DS • Dynamic Host Configuration Protocol Server

• Active Directory Federation Services • Hyper-V
• Active Directory Lightweight Directory • Remote Access (Direct Access)
Services
• Rights Management Services
• Application Server
• Windows Deployment Services
• DNS Server
• Failover Clustering
• File Services
• Network Policy and Access Services
• Print and Document Services
• Remote Access (Web Application Proxy)
• Remote Desktop Services
• Web Server (IIS)
• Windows Server Update Services
There also are some significant Windows Server features that are not currently supported:
• Internet Storage Name Service (iSNS) Server
• Multipath I/O
• Network Load Balancing
• Peer Name Resolution Protocol
• Simple Network Management Protocol (SNMP) Service
• Storage Manager for storage area networks (SANs)
• Windows Internet Name Service
• Wireless local area network (LAN) service
Azure Virtual Machines also support several Linux distributions, including CentOS, CoreOS, Debian, Oracle
Linux, Red Hat, SUSE, openSUSE, and Ubuntu.
Virtual machine sizing

When you create virtual machines in Azure, you
can select from several available sizes and options
for the virtual machine-based compute resources
that run your apps and workloads. There also are
deployment considerations that you need to be
aware of when you plan to provision or deploy
these resources.
Virtual-machine sizes in Azure

Azure offers several virtual-machine size groups
that offer different levels of compute resources,
including:
• A-series. Generally, use this size for general-purpose compute. A-series virtual machines are for
simple production workloads that are not memory-intensive and do not require load balancing or
auto-scaling.
• D-series. Generally, use this size for optimized compute. The hardware configurations that host
D-series virtual machines have faster processors and solid-state drives for applications that require
higher performance.
• G-series. Use this size for performance-optimized compute. G-series virtual machines have the highest
level of compute resources in Azure, and can handle heavy workloads and application demands.
• DS and GS series. These virtual machines are D-series and G-series machines that are for Premium
Storage in Azure specifically. You will learn more about Premium Storage later in this course.
A-series virtual machines are available in two compute tiers--Basic and Standard. The Standard tier
compute instances offer optimal compute, memory, and input/output (I/O) resources, so that you can run
a wide range of applications and workloads. These instances include both auto-scaling, load balancing,
and internal load-balancing capabilities at no additional cost. Both types offer different sizes.
The Basic tier compute instances are similar to the higher-priced Standard tier, but the virtual-machine
instances do not include load-balancing or auto-scaling features. Basic tier VMs are best suited to single-
instance production applications, development workloads, test servers, and batch-processing applications.
Additional Reading: For more information on virtual machine sizes, including any changes
since this course was published, refer to Sizes for virtual machines: http://aka.ms/Iyrbvv.
Sizing considerations
When determining sizing for your Azure Virtual Machines, you should consider the following:
• There are two tiers of Azure Storage for storing your virtual machine’s virtual disks: Standard and
Premium. Premium offers higher I/O throughput, but at a higher pricing level.
• The size of the virtual machine affects the pricing, and the tier affects some capabilities.
• A1 is the smallest size that we recommend for production workloads.
• When deploying a virtual machine for SQL Server Enterprise Edition, select a virtual machine with at
least four CPU cores.
Virtual-machine limits in Azure

When creating IaaS v1 virtual machines in Azure, each cloud service in which those virtual machines reside
can contain a maximum of 50 virtual machines. When you create a new virtual machine, a cloud service is
created automatically to contain it, but you can add more virtual machines in that same cloud service, up
to the 50 virtual-machines limit. You also can have a maximum of 150 input endpoints per cloud service.
There is also a limit of 100 virtual machines in each Azure availability set when you use Azure Resource
Manager.
Additional Reading: For more information on virtual machine limits, including any
changes since this course was published, refer to Azure subscription and service limits, quotas,
and constraints: http://aka.ms/Shfw8w.
The Microsoft Azure (IaaS) Cost Estimator Tool

This tool helps customers understand their existing on-premises infrastructure and estimate the cost
of running it on Azure. It helps to identify the utilization and resource allocation on physical machines
and guest virtual machines running on VMware and Hyper-V. It also determines the cost of running an
on-premises physical or virtual machine workload on Azure over a 30-day period. The tool scans the
hardware and resource utilization over a short period, and typically completes within 15 minutes. The tool
then matches the resulting server profile against Azure IaaS instance types to determine the best fit based
on cost or performance. You also can export the results to Excel or to a CSV file.
The tool can scan any of the following machine types:
• Microsoft virtualization technologies (System Center Virtual Machine Manager, Hyper-V)

• VMware virtualization technologies (vSphere, ESXi)
• Physical infrastructure (Windows, Linux)
You can install the tool on any of the following operating systems:
• Windows Server 2012 and newer versions
• Windows Server 2008 R2 Service Pack 1 (SP1)
• Windows Server 2008 SP2

• Windows Vista SP2
• Windows 7 SP1
• Windows 8.1 and 8
• Windows 10
Additional Reading: To download the Microsoft Azure (IaaS) Cost Estimator tool, refer to:
http://aka.ms/Mg0mhu.
Migrating workloads to Azure

You can migrate on-premises workloads to Azure
by uploading the .VHD file to Azure and attaching
it to an Azure virtual machine. This allows you to
take existing workloads that are running on on-
premises virtual machines and transfer them to
virtual machines that are running in Azure.
Considerations for using .VHD files for

Azure Virtual Machines
You must upload a .VHD file to Azure Storage
before you can attach it to the virtual machine,
and consider several factors, including that:
• .VHD files must be from Hyper-V virtual machines.
• .VHDX files are not supported as Azure virtual machine disks.
• If you are using the .VHD as an image to deploy Windows-based Azure Virtual Machines, you must
generalize the on-premises virtual machine by using sysprep.exe.
• The .VHD file must be a fixed-size virtual disk.
Uploading .VHD files

The following process lists the steps for uploading a .VHD file from a Windows-based virtual machine to
Azure for use as an image to deploy Azure Virtual Machines:
1. Generalize the virtual machine in Hyper-V by running sysprep.exe from the command prompt.
2. In Sysprep, set the System Cleanup Action to Enter System Out-of-Box Experience (OOBE) and
ensure the Generalize check box is selected.
3. Shut down the virtual machine in Hyper-V.
4. Copy the .VHD file to an Internet-connected computer that has the Azure PowerShell module
installed.
5. In the Azure PowerShell window, type the following command, and then press Enter:
Add-AzureRmVhd –ResourceGroupName –Destination

“<BlobStorageURL>/<ContainerName>/<VHDName>.vhd” –LocalFilePath <PathtoVHDFile>
Where:
o BlobStorageURL is the URL for the storage account.
o ContainerName is the container within blob storage where you want to store your images.
o VHDName is the name you want Azure to display to identify the virtual hard disk.
o PathToVHDFile is the full path and name of the .VHD file.

Evaluating the use of Azure containers

A container object in Azure provides a unique
set of features that offers several benefits when
you are running certain workloads within Azure.
In Azure, a virtual machine runs within a
virtualization environment enabled by using a
hypervisor. You create virtual machines by
choosing and configuring the operating system
for the virtual machine, or by using a custom
image. For the most part, virtual machines and the
operating system that they run are isolated from
the host environment.
Azure containers do not require a hypervisor to

enable isolation. The container provides limited exposure to certain outside components, by isolating the
process and file system of the host operating system, which is either Linux or Windows. In most cases, a
container contains an application or reusable service component that acts as part of a larger solution
within Azure. An application within a container sees the container as a unique operating-system instance.
Containers are designed to:
• Increase the speed with which you can develop and share application code.
• Improve the testing lifecycle for applications.
• Improve the deployment process for applications.
In Azure, containers run within an Azure virtual machine, which provides the container that hosts the
environment, which is either Windows or Linux. You can use containers to replace full virtual machines in
many cases, especially when the virtual machine is hosting a component of a distributed application.
Container benefits for IT pros

The combination of containers and virtual machines offers several benefits for developers, and they also
provide benefits for information technology (IT) professionals, including that:
• Services and applications within containers are isolated from the virtual machine host execution
environment.
• Contained code is verifiably identical.
• Developers can start, stop, and move services and applications that are in containers quickly between
development, test, and production environments.
Comparison of virtual machines and containers

The following table lists the high-level differences between virtual machines and containers.
Feature Virtual machines Containers
Security support Greater control of security mechanisms. Lesser control, but easier
implementation.
Memory required Required for complete operating system Required for apps only.
and apps.
Startup time Increased startup time. Boot of operating Lesser startup time. Only apps
system, services, and apps. and dependent services start.
Kernel is already running.
Portability Portable with proper configuration. More portable, typically smaller

in storage size.
Image automation Dependent on operating system and Based on docker registry.

apps.
Additional Reading: For more information about containers, refer to: http://aka.ms/Vrjd2j.
Question: A finance application that employees of A. Datum Corporation use experiences a

relatively low amount of traffic for most of the year, with the exception of the fiscal year’s
end, when the traffic spikes by up to 100 times the normal amount. Is this a suitable
workload for Microsoft Azure, and why?
Lesson 3
Deploying IaaS v2 virtual machines
You can deploy IaaS v2 virtual machines by using several methods within the Azure environment. You
can deploy single virtual machines by using the Azure portal interface, automate the creation of virtual
machines by using Azure PowerShell, or deploy large-scale environments by using Azure Resource
Manager templates. This lesson explains the primary methods for creating IaaS v2 virtual machines, and
it demonstrates these methods.
Lesson Objectives
• Identify the methods to create IaaS v2 virtual machines.
• Explain how to use the Azure portal to create virtual machines.
• Explain how to use Azure PowerShell to create virtual machines.

• Explain how to use Azure Resource Manager templates to create virtual machines.
• Create IaaS v2 virtual machines in Azure.
Creating IaaS v2 virtual machines

Azure Resource Manager provides several
methods to create IaaS v2 virtual machines by
using different tools:
• Azure portal. You can use the Azure portal to

create virtual machines on a one-by-one
basis. Creating virtual machines in the Azure
portal is easy to do in the graphic interface,
but the portal does not provide the ability to
create multiple virtual machines
simultaneously or automate the virtual
machine creation process.
• Azure PowerShell. Azure PowerShell provides

a complete set of cmdlets for creating and configuring virtual machines using the Azure Resource
Manager model. All Azure Resource Manager cmdlets for virtual machine management are of the
form Verb-AzureRmNoun. For example, to create a new virtual machine, you would use the New-
AzureRmVM cmdlet.
You can also use Azure PowerShell to deploy virtual machines using deployment templates. Later
sections of this module provide more detail about deployment templates.
• Azure CLI. You can use the Azure CLI feature to create virtual machines. You can use the CLI on
Windows, Linux, and Mac operating systems. The Azure CLI has a complete set of Azure Resource
Manager commands that you can use, You can also use Azure Service Management commands by
switching the Azure CLI to Azure Resource Manager mode with the following command:
azure config mode asm

To switch back to Azure Resource Manager mode, use the following command:
azure config mode arm
To create an Azure virtual machine using Azure Resource Manager mode, at the command prompt,
type the following command , and then press Enter. You will be prompted to type any information
necessary for virtual machine creation, such as virtual machine name, resource group, and location:
Azure vm quick-create
Note: This is one way to create a virtual machine using the Azure CLI.
Using images to create virtual machines

You can use images to create Azure Virtual Machines. You can capture images from on-premises virtual
machines, or you can use pre-built images from the Azure Marketplace. The Marketplace contains basic
operating-system images and images that are built to provide a specific purpose. The Marketplace
contains hundreds of images in the following categories:
• Microsoft Windows Server

• Numerous Linux distributions
• Database servers
• Application servers
Capturing images that Azure Virtual Machines can use

You can reuse Azure Virtual Machines that you configure to deploy images as new Azure Virtual
Machines. This process saves time when you are configuring new virtual machines by reusing a
configuration that exists already within an Azure Virtual Machine.
To capture an Azure Virtual Machine as an image for reuse in Azure, perform the following steps:
1. Sign in to the virtual machine operating system, and then generalize the image by typing the
following command, and then pressing Enter:
Sysprep /oobe /generalize /shutdown
2. From the Azure PowerShell prompt, sign in to your Azure account.
3. Deallocate the resources of the virtual machine that you are capturing by using the following
command at the command prompt:
Stop-AzureRmVM –ResourceGroupName <ResourceGroupName> -Name <CapturedVMName>
4. Set the status of the virtual machine that you are capturing to Generalize by using the following
command:
Set-AzureRmVM –ResourceGroupName <ResourceGroupName> -Name <CapturedVMName>

-Generalize
5. Capture the virtual-machine image to an existing storage-account container by using the following
command:
Save-AzureRmVMImage -ResourceGroupName <ResourceGroupName> -VMName <CapturedVMName>

-DestinationContainerName <StorageContainerName> -VHDNamePrefix <PrefixName>
Additional Reading: For more information about capturing and deploying virtual machine
images by using Azure Resource Manager, refer to: http://aka.ms/Cey939.
Using the Azure portal to create virtual machines

To create an IaaS v2 virtual machine from the
Azure portal, perform the following steps:
1. Sign in to the Azure portal at

2. On the Hub menu, click New, click Compute,

and then click Windows Server 2012 R2
Datacenter.
3. On the Windows Server 2012 R2

Datacenter page, under Select a
deployment model, select Resource
Manager, and then click Create.
4. On the Create virtual machine blade, click Basics.
5. Enter the name that you want to give your virtual machine. The name cannot contain special
characters.
6. Enter the Windows administrative user name and password. The password must be at eight to 123
characters long, and include at least three of the following: one lower-case character, one upper-case
character, one number, and one special character. You will need the user name and password to sign
in to the virtual machine.
7. If you have more than one subscription, specify the one for the new virtual machine, a new or existing
resource group, and an Azure datacenter location.
8. Click Size, and then select an appropriate virtual-machine size for your needs. Each size specifies the
number of compute cores, memory, and other features, such as support for Premium Storage. These
all affect the price. Azure recommends certain sizes automatically, depending on the image that you
choose.
9. Click Settings to see storage and networking settings for the new virtual machine. For a test virtual
machine, you typically can accept the default settings. If you select a virtual-machine size that
supports it, you can try out Premium Storage by selecting Premium (SSD) under Disk type.
10. Click Summary to review your configuration choices. When you finish reviewing or updating the
settings, click Create.
As Azure creates the virtual machine, you can track the progress under Virtual Machines on the Hub
menu.
These steps use the image based on Windows Server 2012 R2 Datacenter Edition to create an IaaS v2
virtual machine.
Using Azure PowerShell to create virtual machines

You can use Azure PowerShell to create virtual
machines from the Azure PowerShell command
prompt, or by using Azure PowerShell scripts.
When you use Azure Resource Manager cmdlets
to create Azure Virtual Machines, you can take
advantage of the RBAC and group-management
features that Azure Resource Manager provides.
To create an IaaS v2 virtual machine by using

Azure PowerShell, perform the following steps:
1. Open the Azure PowerShell command
prompt.
2. Sign in to Azure by typing the following cmdlet, and then pressing Enter:
3. Retrieve the Azure subscription name that you want to use by viewing the list of subscriptions after
typing the following command, and then pressing Enter:
Get-AzureRmSubscription | sort SubscriptionName | Select SubscriptionName
4. Set your subscription by typing the following cmdlet, and then pressing Enter:
Select-AzureRmSubscription -SubscriptionName "<subscription name>"
<subscription name> is the name of the subscription that you chose from the list that was returned in
step 3.
5. Use the following code block to create the virtual machine, storage account, and associated network
objects. In the code, you must replace <chosen storage account name> and <chosen Azure location
name> with the appropriate values from your environment.
$stName = "<chosen storage account name>"

$locName = "<chosen Azure location name>"
$rgName = "TestRG"
New-AzureRmResourceGroup -Name $rgName -Location $locName
$storageAcc = New-AzureRmStorageAccount -ResourceGroupName $rgName -Name $stName
-Type "Standard_GRS" -Location $locName
$singleSubnet = New-AzureRmVirtualNetworkSubnetConfig -Name singleSubnet
$vnet = New-AzureRmVirtualNetwork -Name TestNet -ResourceGroupName $rgName -Location
$locName -AddressPrefix 10.0.0.0/16 -Subnet $singleSubnet
$pip = New-AzureRmPublicIpAddress -Name TestPIP -ResourceGroupName $rgName -Location
$locName -AllocationMethod Dynamic
$nic = New-AzureRmNetworkInterface -Name TestNIC -ResourceGroupName $rgName -Location
$locName -SubnetId $vnet.Subnets[0].Id -PublicIpAddressId $pip.Id
$cred = Get-Credential -Message "Type the name and password of the local
administrator account."
$vm = New-AzureRmVMConfig -VMName WindowsVM -VMSize "Standard_A1"
$vm = Set-AzureRmVMOperatingSystem -VM $vm -Windows -ComputerName MyWindowsVM
-Credential $cred -ProvisionVMAgent -EnableAutoUpdate
$vm = Set-AzureRmVMSourceImage -VM $vm -PublisherName MicrosoftWindowsServer -Offer
WindowsServer -Skus 2012-R2-Datacenter -Version "latest"
$vm = Add-AzureRmVMNetworkInterface -VM $vm -Id $nic.Id
$osDiskUri = $storageAcc.PrimaryEndpoints.Blob.ToString() +
"vhds/WindowsVMosDisk.vhd"
$vm = Set-AzureRmVMOSDisk -VM $vm -Name "windowsvmosdisk" -VhdUri $osDiskUri
-CreateOption fromImage
New-AzureRmVM -ResourceGroupName $rgName -Location $locName -VM $vm
Additional Reading: For more information on creating IaaS v2 virtual machines by using
Azure, refer to: http://aka.ms/J6lqcj.
Creating virtual machines by using a deployment template

You can deploy virtual machines in Azure
PowerShell by using an Azure Resource Manager
template, which you can use as a reusable
definition for virtual-machine deployment.
Azure Resource Manager templates help to:
• Deploy Azure solutions and their workloads

consistently.
• Manage all of your Azure resources in a

solution put together by using resource
groups.
• Apply RBAC to specify access to users, groups,

and services.
• Use tagging to streamline resource-based identification and auditing tasks.
You create Azure Resource Manager templates as JavaScript Object Notation (JSON) files that contain
definitions of virtual machines and other Azure objects for deployment or configuration. The following
code is part of a JSON template for the deployment of an Azure IaaS v2 virtual machine:
{
"$schema": "http://schema.management.azure.com/schemas/2014-04-01-
preview/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"newStorageAccountName": {
"type": "string",
"metadata": {
"Description": "Unique DNS name for the storage account where the virtual
machine's disks will be placed."
}
},
"adminUsername": {
"type": "string",
"metadata": {
"Description": "User name for the virtual machine."
}
},
"adminPassword": {
"type": "securestring",
"metadata": {
"Description": "Password for the virtual machine."
}
},
"dnsNameForPublicIP": {
"type": "string",
"metadata": {
"Description": "Unique DNS Name for the Public IP used to access the virtual
machine."
}
},
"windowsOSVersion": {
"type": "string",
"defaultValue": "2012-R2-Datacenter",
"allowedValues": [
"2008-R2-SP1",
"2012-Datacenter",
"2012-R2-Datacenter",
"Windows-Server-Technical-Preview"
],
"metadata": {
"Description": "The Windows version for the virtual machine. This will pick a
fully updated image of this given Windows version. Allowed values: 2008-R2-SP1, 2012-
Datacenter, 2012-R2-Datacenter, Windows-Server-Technical-Preview."
}
}
},
"variables": {
"location": "West US",
"imagePublisher": "MicrosoftWindowsServer",
"imageOffer": "WindowsServer",
"OSDiskName": "osdiskforwindowssimple",
"nicName": "myVMNic",
"addressPrefix": "10.0.0.0/16",
"subnetName": "Subnet",
"subnetPrefix": "10.0.0.0/24",
"storageAccountType": "Standard_LRS",
"publicIPAddressName": "myPublicIP",
"publicIPAddressType": "Dynamic",
"vmStorageAccountContainerName": "vhds",
"vmName": "MyWindowsVM",
"vmSize": "Standard_D1",
"virtualNetworkName": "MyVNET",
"vnetID":
"[resourceId('Microsoft.Network/virtualNetworks',variables('virtualNetworkName'))]",
"subnetRef": "[concat(variables('vnetID'),'/subnets/',variables('subnetName'))]"
},
Deploying a virtual machine by using a template

To utilize the definitions hosted within a JSON template such as the one above, you must use the
New-AzureRMResourceGroupDeployment cmdlet with the –Template switch. The following example
creates an Azure Resource Manager resource group named TestRG, and then deploys the template
contents into the resource group in the West US region:
$deployName="TestDeployment"
$RGName="TestRG"
$locname="West US"
$templateURI="https://raw.githubusercontent.com/Azure/azure-quickstart-
templates/master/101-simple-windows-vm/azuredeploy.json"
New-AzureRmResourceGroup –Name $RGName –Location $locName
New-AzureRmResourceGroupDeployment -Name $deployName -ResourceGroupName $RGName
-TemplateUri $templateURI
Additional Reading: For more information on deploying IaaS v2 virtual machines by using
Azure PowerShell and Azure Resource Manager templates, refer to: http://aka.ms/Bt1gf6.
Demonstration: Creating a virtual machine by using the Azure portal

In this demonstration, you will see how to create a virtual machine by using the Azure portal.
Demonstration Steps
1. In Internet Explorer, navigate to https://portal.azure.com. Sign in using the Microsoft account that
is either the Service Administrator or Co-administrator of your subscription.
2. From the Hub menu, create a new IaaS v2 virtual machine with the following properties:
o Name: AdatumTestVM1
o User name: Instructor
o Password: Pa$$w0rd
o Resource Group: TestRG1
o Size: A1 Standard
Question: Why is an Azure Resource Manager template beneficial for deploying multiple
virtual machines?
Lab A: Creating IaaS v2 virtual machines in Azure

Scenario
As part of the planning for deployment of IaaS v2 virtual machines to Azure, A. Datum has evaluated its
deployment options. You must use the Azure portal and Azure PowerShell to deploy two Windows virtual
machines for the Database tier of the Research and Development application. Additionally, to facilitate
resource tracking, you should ensure that the virtual machines are part of the same resource group.
Objectives
• Create virtual machines by using the Azure portal and Azure PowerShell.
• Validate virtual-machine creation.
Lab Setup

User name: Student
Password: Pa$$w0rd
Exercise 1: Creating virtual machines by using the Azure portal and

Azure PowerShell
Scenario
You must deploy two virtual machines that are running Windows Server 2012 R2 Datacenter. Name
these machines ResDevDB1 and ResDevDB2, and use them as database servers for the Research and
Development app, ResDev. You will use the Azure portal to deploy one of the virtual machines, and you
will use Azure PowerShell to deploy the other VM. You must deploy both virtual machines into the
ResDevRG resource group, and you must configure the virtual machines to use the database subnet of the
HQ-VNET virtual network. After deploying the virtual machines, you will confirm that the virtual machines
are deployed to the correct resource group and are on the database subnet.

1. Use the Azure portal to create a virtual machine.
2. Use Azure PowerShell to create a virtual machine.
 Task 1: Use the Azure portal to create a virtual machine

1. On MIA-CL1, in Internet Explorer, navigate to the Azure portal.
2. Sign in using the Microsoft account that is either the Service Administrator or Co-administrator of
your subscription.
3. From the Azure portal, create an IaaS v2 virtual machine with the following parameters:
o Name: ResDevDB1
o Subscription: Your subscription

o Resource group: ResDevRG
o Location: Accept the default location, which should match the location of the resource group.
o Size: A1 Standard
o Network name: HQ-VNET
o Subnet name: Database
 Task 2: Use Azure PowerShell to create a virtual machine

1. On MIA-CL1, open a Windows PowerShell Integrated Scripting Environment (ISE) window. In the
Windows PowerShell ISE, open the script D:\Labfiles\Lab03\Starter\CreateRmVM.ps1 and review
its content.
2. Run the script.
3. When prompted to sign in, type the name of the account that is either the Service Administrator or
Co-administrator of your Azure subscription.
4. If you have multiple subscriptions, select the one to use in the labs in this module.
5. When the script is complete, leave the Windows PowerShell ISE window open.
Results: After completing this exercise, you will have created virtual machines by using the Azure portal
and Azure PowerShell.
Exercise 2: Validating virtual-machine creation

Scenario
You now must validate the creation and configuration of the virtual machines that you created to ensure
that they function properly.
1. Use Azure PowerShell to validate virtual-machine deployment.
2. Use the Azure portal to validate virtual-machine deployment.
 Task 1: Use Azure PowerShell to validate virtual-machine deployment

1. In the Windows PowerShell ISE window, at the command prompt, type the following command, and
then press Enter:
Get-AzureRmResource | where {$_.ResourceType –like “*VirtualMachines”}
2. Confirm that the ResDevDB1 and the ResDevDB2 virtual machines are listed. Note that both virtual
machines belong to the ResDevRG resource group.
 Task 2: Use the Azure portal to validate virtual-machine deployment

1. On MIA-CL1, in the Internet Explorer window, in the Azure portal, view the virtual machine resources.
2. Confirm that both ResDevDB1 and ResDevDB2 have been created, that they belong to the
ResDevRG resource group, and that they reside on the Database subnet of the HQ-VNET virtual
network.
Results: After completing this exercise, you will have validated the creation and configuration of Azure
Virtual Machines.
Question: What storage-related differences did you notice when you created a virtual
machine in the Azure portal versus in Azure PowerShell?
Lesson 4
Authoring Azure Resource Manager templates
You use Azure Resource Manager templates to deploy large and complex Azure environments. As a result,
the syntax and definition of resource templates can contain a complex environment of variable, resource,
and parameter definitions that control deployment. If you want to create and manage Azure Resource
Manager template files, you must understand the basic composition of resource template files, and the
JSON standard that governs the syntax of these files. This lesson shows you how to understand, modify,
and create your own JSON-based Azure Resource Manager templates for use in deploying virtual
machines in your environment.
Lesson Objectives
• Explain the structure of Azure Resource Manager templates.

• Explain how to modify Azure Resource Manager templates.
• Author an Azure Resource Manager template.
Azure Resource Manager templates overview

Azure Resource Manager templates contain JSON
expressions that define one or more Azure
resources. Resource templates use the .json
file name extension, and you can name them with
any convention that best suits your organization.
When creating and working with resource
templates, you should consider:
• Which resources you are going to deploy.

• Where your resources will be located.
• Which version of the resource provider API

you will use.
• Whether there are dependencies between resources.
• When you will define deployment values. You can define them before creation, in the template, or
during deployment.
• If you want to retain deployment information or values.
The resources that you choose to deploy must be available in the region that you select for deployment.
Some Azure regions do not support all resource types, and availability will vary from region to region.
Understanding the structure of a resource template

In its simplest form, a resource template is similar to the following code sample:
{
"$schema": "http://schema.management.azure.com/schemas/2015-01-
01/deploymentTemplate.json#",
"contentVersion": "",
"parameters": { },
"variables": { },
"resources": [ ],
"outputs": { }
}
The following table describes the sections in the code sample above.
Element name Required Description
$schema Yes This is the location of the JSON schema file, which describes
the template language.
contentVersion Yes This arbitrary value defines the template’s version. You can
use any value that is helpful in tracking template versioning.
parameters No These values are provided during the deployment process to

customize resource deployments.
variables No These hold large or complex values, or values that

frequently repeat in the template. Variables help to simplify
JSON expressions in the template.
resources Yes These are resource types that you create or modify as part
of the deployment.
outputs No These values are returned during and after deployment.
The next topic discusses these sections in more detail.

The following code comprises a complete template that deploys a web app and uses code from a .zip file
to provision the app:
{
"$schema": "http://schema.management.azure.com/schemas/2015-01-
01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"siteName": {
"type": "string"
},
"hostingPlanName": {
"type": "string"
},
"hostingPlanSku": {
"type": "string",
"allowedValues": [
"Free",
"Shared",
"Basic",
"Standard",
"Premium"
],
"defaultValue": "Free"
}
},
"resources": [
{
"apiVersion": "2014-06-01",
"type": "Microsoft.Web/serverfarms",
"name": "[parameters('hostingPlanName')]",
"location": "[resourceGroup().location]",
"properties": {
"sku": "[parameters('hostingPlanSku')]",
"workerSize": "0",
"numberOfWorkers": 1
}
},
{
"apiVersion": "2014-06-01",
"type": "Microsoft.Web/sites",
"name": "[parameters('siteName')]",
"tags": {
"environment": "test",
"team": "ARM"
},
"dependsOn": [
"[resourceId('Microsoft.Web/serverfarms', parameters('hostingPlanName'))]"
],
"properties": {
"serverFarm": "[parameters('hostingPlanName')]"
},
"resources": [
{
"apiVersion": "2014-06-01",
"type": "Extensions",
"name": "MSDeploy",
"dependsOn": [
"[resourceId('Microsoft.Web/sites', parameters('siteName'))]"
],
"properties": {
"packageUri":
"https://auxmktplceprod.blob.core.windows.net/packages/StarterSite-modified.zip",
"dbType": "None",
"connectionString": "",
"setParameters": {
"Application Path": "[parameters('siteName')]"
}
}
}
]
}
],
"outputs": {
"siteUri": {
"type": "string",
"value": "[concat('http://',reference(resourceId('Microsoft.Web/sites',
parameters('siteName'))).hostNames[0])]"
}
}
}
Additional Reading: For more information on Azure Resource Manager template

structure, refer to: http://aka.ms/Yxslmx.
Modifying Azure Resource Manager templates

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

Templates include parameters, variables,
resources, and outputs. The following text
provides specific information about each template
section and the type of code that the section
contains.
Parameters
Parameters define the values that an administrator can input during the deployment process. With
parameters, you can specify customizations to the deployment process and make a template more flexible
and adaptable to different environments and uses. For example, you might declare a parameter that
allows you to specify an Azure region. Without this parameter, you must define the Azure region
specifically in the template, making the template only usable for one region. However, when you use this
parameter, you can choose which region to use for your deployment.
You can define each parameter by using the elements that the following table describes.
parameterName Yes This is the parameter’s name, and it must be a valid

JavaScript identifier.
type Yes This is the parameter type, and can be a string, integer,
Boolean, object, or array.
defaultValue No This value is assigned automatically to the parameter, if

you do not assign one.
allowedValues No This is an array or list of values that define exactly

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

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

parameters.
Description No This description of the parameter displays to users of

the template. This description is optional.
The following code provides examples of parameters, as defined in a sample template file:
"parameters": {
"siteName": {
"type": "string",
"minLength": 2,
"maxLength": 60
},
"siteLocation": {
"type": "string",
"minLength": 2
},
"hostingPlanName": {
"type": "string"
},
"hostingPlanSku": {
"type": "string",
"allowedValues": [
"Free",
"Shared",
"Basic",
"Standard",
"Premium"
],
"defaultValue": "Free"
Variables
Variables contain values that you can reuse throughout your template. Variables typically are based on
values that you provide by using parameters, and typically are often combined or computed. The
following code provides examples of variables as defined in a sample template file:
"variables": {
"environmentSettings": {
"test": {
"instancesSize": "Small",
"instancesCount": 1
},
"prod": {
"instancesSize": "Large",
"instancesCount": 4
}
},
"currentEnvironmentSettings":
"[variables('environmentSettings')[parameters('environmentName')]]",
"instancesSize": "[variables('currentEnvironmentSettings').instancesSize",
"instancesCount": "[variables('currentEnvironmentSettings').instancesCount"
}
Resources
The resources section is where you define how the majority of the deployment process occurs. Resource
types can be inherently complex, and constructing the resources section of your template requires
knowledge of the types that you are deploying.
You define resources by using the elements in the following table.
apiVersion Yes This is the version of the representational state transfer

(REST) API that you use to create the resource.
type Yes This is the resource type, which is a combination of the

resource provider namespace and the resource type that
the provider supports.
name Yes This is the resource name, and it must follow Uniform
Resource Identifier (URI) component restrictions.
location No This is the supported datacenter location for the provided

resource.
tags No These are tags that are associated with the resource.
comments No These are your documentation notes for the resource.
dependsOn No These are other resources on which this resource depends,

or parent resources. The dependsOn element and the
resources element determine the order in which resources
deploy. If you do not specify either element, resources
deploy in parallel.
properties No These are resource-specific settings. You specify these by

using REST API operation values.
resources No These child resources depend on this resource for their

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

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

• add(): This function returns the sum of two integers. For example, add(2,5) returns an integer value
of 7.
• concat(): This function combines two or more string or array values into a single string or array value.
For example, concat(‘Hello,’World’) returns a string value of ‘HelloWorld’.
• toLower(): This function converts a string to entirely lower-case characters. For example
toLower(‘Adatum’) returns a string value of ‘adatum’.
• parameters(): This function returns the value of a parameter that has been defined in the template.
For example, parameters(‘locName’) returns the value specified by the template user for the
locName parameter.
Additional Reading: For more information about Azure Resource Manager template
functions, refer to: http://aka.ms/Jcr7f7.
Demonstration: Authoring an Azure Resource Manager template

• Open an Azure Resource Manager template in Visual Studio.
• View the different sections of an Azure Resource Manager template.
Demonstration Steps
1. On MIA-CL1, open the Visual Studio solution located at D:\Labfiles\Lab03\Starter\ResDev
\ResDevLinuxDeploy\ResDevLinuxDeploy.sln.
2. View the contents of the azuredeploy.json template.
3. Initiate the deployment process, but do not complete it.

Reset-Azure
demos and labs in the next module.
directory.
Question: What purpose do resource groups have when you deploy Azure resources by
using Azure Resource Manager templates?
Lesson 5
Overview of IaaS v1 virtual machines
As a best practice, use IaaS v2 virtual machines for Azure implementations in a production environment
because of the full feature set of IaaS v2 infrastructure when compared to IaaS v1. IaaS v2 is also the
default implementation model that the Azure portal and the Azure CLI use. Although we do not
recommend IaaS v1 virtual machines for a common production deployment, your environment might
have existing IaaS v1 virtual machines that you need to manage. This lesson covers the basics of IaaS v1
components, and details how you can create and manage IaaS v1 virtual machines.
Lesson Objectives
• Explain the concept of IaaS Cloud Services.
• Describe how to create IaaS v1 virtual machines.
Overview of IaaS Cloud Services

IaaS Cloud Services are similar to the PaaS Cloud
Services, which you can use to host web and
worker roles. For more information about PaaS,
refer to “Module 8: Implementing PaaS Cloud
Services”.
In both IaaS v1 and PaaS v1, the cloud service is

the network container for hosting Azure Virtual
Machines. You cannot create an Azure virtual
machine without first specifying a cloud service
to use.
Any virtual machine in a cloud service can
communicate directly with all other virtual
machines in that cloud service by using Azure communications. All communications within a cloud service
are internal to that cloud service only, and virtual machines are not using the Internet to communicate
with each other.
A built-in Azure DNS server provides name resolution for all virtual machines within the same cloud
service. If you want to extend this name resolution, you will need to configure your own DNS solution.
An example of when you might do this is if you want to include on-premises resources.
Cloud services have an assigned, DNS name that is accessible publically, and that takes the form unique
cloud service name.cloudapp.net. A cloud service has at least one VIP address assigned, and the cloud
service VIP allows inbound connections to Azure Virtual Machines from the Internet.
The Cloud Services object is part of IaaS v1 and the Azure Service Management model. For general
deployment of Azure IaaS resources, we recommend IaaS v2 and the Azure Resource Manager model,
as previously discussed in this lesson.
Creating IaaS v1 virtual machines

If you use the Classic Portal, you can either use
the QUICK CREATE option to provision a virtual
machine rapidly, and then configure and
customize it later, or use the FROM GALLERY
option to select an image from the gallery, and
configure it.
When you use the QUICK CREATE method, you

only need to provide the following information to
provision a virtual machine:
• A DNS name for the virtual machine.
• An image from which to provision the virtual

machine.
• A pricing-tier size for the virtual machine. A1 is the default for a Windows-based virtual machine.
• A user name and password.
• A region or affinity group.
When you use the FROM GALLERY option, you need to provide more information to provision a virtual
machine, including:
• An image from the gallery.
• A version-release date for the image to ensure that they have the most up-to-date version.
• A VM name.
• A pricing-tier size for the virtual machine. A1 Standard is the default for a Windows-based virtual
machine.
• A user name and password.
• A Cloud Service in which to create the virtual machine. Either create a new one or select an existing
one.
• A region, affinity group, or virtual network in which to deploy the virtual machine.
• A storage account.
• An availability set (optional).
• Additional endpoints (optional).
• An install VM Agent (optional).
• Configuration and security extensions (optional).

Deploying virtual machines by using Azure PowerShell

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

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

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

Resource Manager templates
Scenario
You must use an Azure Resource Manager template to deploy two additional Linux virtual machines and
two additional Windows virtual machines that the ResDev application will use. The virtual machines
should be part of the ResDevRG resource group, to facilitate resource tracking. Linux virtual machines
should reside on the app subnet of the HQ-VNET virtual network, and Windows virtual machines should
reside on the web subnet of the HQ-VNET virtual network.
Objectives
After completing this lab, you must be able to:
• Use Visual Studio and an Azure Resource Manager template to deploy IaaS v2 virtual machines.
• Use Azure PowerShell and an Azure Resource Manager template to deploy virtual machines.
Lab Setup

User name: Student
Password: Pa$$w0rd
The virtual machine should be running from the previous lab.
Exercise 1: Using Visual Studio and an Azure Resource Manager template

to deploy IaaS v2 virtual machines
Scenario
You must use Visual Studio to deploy two Linux IaaS v2 virtual machines for use as app servers in the
ResDev app. You should name the servers ResDevApp1 and ResDevApp2. You have a deployment-
template solution and the deployment details for both virtual machines. You must deploy the two virtual
machines from Visual Studio, and then confirm that the virtual machines have been deployed successfully
by using Azure PowerShell.
1. Use Visual Studio to deploy the Linux app server’s virtual machines.
2. Use Azure PowerShell to validate the deployment of the app server’s virtual machines.
 Task 1: Use Visual Studio to deploy the Linux app server’s virtual machines
1. On MIA-CL1, open the Visual Studio solution located at D:\Labfiles\Lab03\Starter\ResDev
\ResDevLinuxDeploy.
2. View the contents of the azuredeploy.json template.
3. In the Solution Explorer, right-click ResDevLinuxDeploy, and then start a new deployment process
for the first virtual machine.
4. Deploy a new virtual machine into the ResDevRG resource group, by using the following parameter
values:
o vmName: ResDevApp1
o adminUsername: Student
o adminPassword: Pa$$w0rd
o virtualNetworkName: HQ-VNET
o resourceGroupName: ResDevRG
o subnetName: App
o vmSize: Standard_D1
o ubuntuOSVersion: 14.04.2-LTS
o storageAccountType: Standard_LRS
o Save password: enabled
Note: Deployment will run with the output that appears in the Output pane, which is at the
bottom of the window. When deployment is complete, you will receive a message stating that
the template was deployed successfully to resource group ResDevRG.
5. View the contents of the Azuredeploy.parameters.json file to see that the parameters that you
entered have been saved in this file.
6. Start another deployment process by using the deployment that you used for the first virtual
machine.
7. Repeat step 4, changing only the following parameter:

Note: Deployment will run with the output that appears in the Output pane, which is at the
bottom of the window. When deployment is complete, you will receive a message stating the
template was deployed successfully to resource group ResDevRG.
8. Close the solution but leave Visual Studio open.
 Task 2: Use Azure PowerShell to validate the deployment of the app server’s virtual
machines
1. On MIA-CL1, launch Windows PowerShell ISE as Administrator.
2. With the Service Administrator or Co-administrator credentials, sign in to the subscription to which
you deployed virtual machines in the previous task of this exercise by using the following cmdlet:
3. If you have multiple subscriptions associated with your account, at the Windows PowerShell ISE
prompt, type the following cmdlet, and then press Enter:
4. Identify the name of the Azure subscription to which you deployed virtual machines in the previous
task of this exercise, type in the following cmdlet, and then press Enter (replace ‘Name of your
subscription’ with the actual name of your subscription and make sure to enclose the name of your
subscription in single quotes):
Set-AzureRmContext –SubscriptionName ‘Name of your subscription’
5. In the Windows PowerShell ISE, at the command prompt, type the following cmdlet, and then press
Enter:
Find-AzureRMResource –ResourceGroupNameContains ResDevRG | Format-Table –Property

ResourceName, ResourceType
6. In the cmdlet output, note the resources created in this exercise: ResDevApp1 and ResDevApp2
virtual machines, and an NIC, public IP, and storage account for each virtual machine.
7. Leave the Windows PowerShell ISE window open for the next exercise.
Results: After completing this exercise, you will have deployed Azure Virtual Machines by using Visual
Studio and an Azure Resource Manager template.
Exercise 2: Using Azure PowerShell and an Azure Resource Manager

template to deploy virtual machines
Scenario
You must deploy the Web tier virtual machines by using an Azure Resource Manager template and the
Azure portal. The Web tier should consist of two virtual machines that are running Windows Server 2012
R2, ResDevWeb1 and ResDevWeb2. You should deploy them to the ResDevRG resource group, and then
host them on the web subnet of the HQ-VNet virtual network. You have a template and a Windows
PowerShell script that you should edit to complete the deployment. After you deploy the virtual
machines, confirm the deployment by viewing the newly deployed resources in the Azure portal.
1. Use Azure PowerShell to deploy the Windows virtual machines.
2. Use the Azure portal to validate deployment of the Windows virtual machines.
 Task 1: Use Azure PowerShell to deploy the Windows virtual machines

1. In the Windows PowerShell ISE window that you opened in the previous exercise, open
D:\Labfiles\Lab03\Starter\ResDev\ ResDevWindowsDeploy.ps1.
2. Review the script that will initiate the template.
Note: Note the $templateFile and $rgName variables. These represent the location of the
Azure Resource Manager template file and the resource group to which you will deploy the
virtual machines.
3. Switch to Visual Studio and open the file D:\Labfiles\Lab03\Starter\ResDev

\ResDevWindowsDeployTemplate.json.
Note: Note that the template has the same structure as the template for the Linux virtual
machines in the previous exercise. The only difference between the two templates is the variables
declaring the image and operating system details.
4. Close Visual Studio.
5. Switch back to the Windows PowerShell ISE window and run the ResDevWindowsDeploy.ps1 script.
When prompted, provide the following values:
o vmName: ResDevWeb1
o subnetName: Web
6. When the script completes, repeat step 5, changing only the value of the vmName parameter to
ResDevWeb2.
 Task 2: Use the Azure portal to validate deployment of the Windows virtual
machines
1. In Internet Explorer, browse to the Azure portal.
your subscription.
3. Navigate to the blade of the ResDevRG resource group.
4. On the ResDevRG resource group blade, view the full list of its resources.
Note: Note the virtual machines, and the NIC and public IP resources for each virtual
machine.
5. View the details for the ResDevWeb1 virtual machine. On the ResDevWeb1 blade, note that
ResDevWeb1 has been assigned to the HQ-VNet/Web virtual network/subnet, and the operating
system is Windows.
6. Close Internet Explorer.

Reset-Azure

The script will take 5-10 minutes to reset your Microsoft Azure environment, and prepare it for
the next lab.
groups.
(you will see an error, if this occurs). If you still find objects after the reset script is complete, you
can rerun the Reset-Azure script, or use the full Azure portal to manually delete all the objects in
your Azure subscription, with the exception of the default directory.
Results: After completing this exercise, you will have deployed Azure Virtual Machines by using Windows
PowerShell and a Resource Manager template.
Question: Can Visual Studio and Windows PowerShell use the same Azure Resource
Manager template to deploy a virtual machine?
Question: How would you configure an Azure Resource Manager template to deploy
multiple virtual machines with different configurations?

Review Questions
Question: Can you migrate on-premises virtual machines directly to Azure?
Question: What tools can you use to implement Azure Resource Manager templates?
Best Practices
• Use IaaS v2 virtual machines for new virtual-machine and solution deployments.
• Use Azure Resource Manager resource groups to manage and deploy virtual machines.
• Use a consistent naming convention for your IaaS infrastructure.
• Use Azure Resource Manager templates to deploy and modify virtual machines that have the same
management or operational lifecycle.
4-1
Module 4
Managing virtual machines
Contents:
Module Overview 4-1
Lesson 1: Configuring virtual machines 4-2
Lesson 2: Configuring virtual machine disks 4-11
Lesson 3: Managing and monitoring Azure virtual machines 4-17
Lesson 4: Managing IaaS v1 virtual machines 4-28
Lab: Managing Azure virtual machines 4-32

Module Overview
Configuration, management, and monitoring of Azure infrastructure-as-a-service (IaaS) Virtual Machines
are essential in delivering secure, available, and scalable cloud-based solutions. In this module, you will
see some of the most common techniques that allow you to modify and maintain Azure virtual machines
and operating system characteristics in order to better suit your custom requirements.
Objectives
• Configure virtual machines.
• Configure virtual machine disks.
• Manage and monitor virtual machines.

4-2 Managing virtual machines
Lesson 1
Configuring virtual machines
Virtual machines constitute one of the core components of Microsoft Azure IaaS deployments. In this
lesson, you will look at the different options that you can use to configure availability, scalability, and
performance of the Azure virtual machine environment.
Lesson Objectives
• Describe how to configure virtual machine availability.
• Describe how to configure virtual machine scalability.

• Describe how to configure virtual machine security.
• Describe how to configure virtual machine availability sets.

In this demonstration, you will see how to prepare the Azure environment.
Demonstration Steps
2. Type the following command, and press Enter:
Setup-Azure
3. At the command prompt, type 4, and then press Enter.
4. Confirm your selection, and press Enter.
5. After the script completes running, close the Windows PowerShell command prompt.
Configuring virtual machine availability

In general, you want your Azure virtual machine
environment to be resilient to hardware failures
and maintenance events that might occur
occasionally within the Azure infrastructure. The
primary mechanism provided by the Azure
platform that helps you accomplish this objective
is the availability set feature. Availability sets are
designed to gracefully handle two event types
that might result in downtime of individual Azure
virtual machines:
• Planned outages. These outages occur

because of planned system maintenance
events that require a temporary virtual machine downtime. In particular, while most Azure platform
updates are transparent to platform as a service (PaaS) and IaaS infrastructure, some of them might
involve reboots of Hyper-V hosts. To accommodate such types of events, Azure implements update
domains. Update domain is explained later in this topic.
• Unplanned outages. These outages can negatively affect availability of individual virtual machines in
an unexpected way, and potentially for longer than the time frame of a planned Hyper-V host restart.
While the Azure platform is designed to be highly resilient, there might be cases where a hardware
failure results in virtual machine downtime. In Azure, unplanned outage events are mitigated by using
fault domains. Fault domain is explained later in this topic.
Understanding availability sets

To provide resiliency for your IaaS-based solutions, you should group two or more virtual machines
providing the same functionality in an availability set. An availability set is a logical grouping of two or
more virtual machines. By assigning virtual machines to the same availability set, you automatically
distribute them across separate fault domains and separate update domains.
Update domains
An availability set consists of up to 20 update domains (you have the ability to increase this number from
its default of 5). Each update domain represents a set of physical hosts that Azure Service Fabric can
update and reboot at the same time without affecting overall availability of virtual machines grouped in
the same availability set.
When you assign more than five virtual machines to the same availability set (assuming the default
settings), the sixth virtual machine is placed into the same update domain as the first virtual machine,
the seventh in the same update domain as the second virtual machine, and so on. During planned
maintenance, only hosts in one of these five update domains are rebooted concurrently, while hosts in
the other four remain online.
Fault domains
Fault domains define a group of Hyper-V hosts that, due to their placement, could be affected by a
localized failure (such as servers installed in a rack serviced by the same power source or networking
switches). Azure Service Fabric distributes VMs in the same availability set across either two (with Azure
classic deployment) or up to three (when using Azure Resource Manager) fault domains.
By placing application servers, such as web or database servers in function-based availability sets and then
using load balancing (discussed in the next topic) or additional failover mechanism, you can protect each
service and enable traffic to be continuously served by at least one instance of each service.
Configuring availability sets

Availability set configuration is mostly governed by the Azure Service Fabric, and, beyond the initial setup
and VM assignment, does not require user interaction. To add one or more virtual machines to an
availability set, simply assign the same availability set on their Settings blade. The portal also allows you to
create a new availability set by offering it as one of its Azure Marketplace components in the Compute
category.
Azure PowerShell provides an alternative approach to managing availability sets. The following cmdlets
handle creating, modifying, and removing availability sets respectively:
New-AzureRmAvailabilitySet
Set-AzureRmAvailabilitySet
Remove-AzureRmAvailabilitySet
Considerations for virtual machine availability

When configuring availability sets for Azure virtual machines:
• Configure two or more virtual machines in an availability set for redundancy. The primary purpose of
an availability set is to provide resiliency to failure of a single virtual machine. If you do not use
multiple virtual machines in an availability set, you gain no benefit from the availability set. In
addition, for Internet facing virtual machines to qualify for 99.95% external connectivity Service Level
Agreement (SLA), they must be part of the same availability set (with two or more VMs per set).
Note: It is critical to understand that it is not possible to add an existing Azure virtual
machine to an availability set. You need to specify that a virtual machine will be part of an
availability set when you provision it.
• Configure each application tier as a separate availability sets. As long as virtual machines in your
deployment provide the same functionality, such as web service or database management system,
you should configure them as part of the same availability set to ensure that at least one VM in each
tier is always available.
• Wherever applicable, combine load balancing with availability sets. You can implement an Azure load
balancer in conjunction with an availability set to distribute incoming connections among its virtual
machines, as long as the application running on them supports such configuration. In addition to
distributing incoming connections, a load balancer is capable of detecting a virtual machine or an
application failure and redirect network traffic to other nodes in the availability set.
Configuring virtual machine scalability

You can provide scalability of IaaS virtual
machines in Azure by using Azure Virtual Machine
Scale Sets. A VM scale set consists of a group of
automatically provisioned Windows or Linux
virtual machines that share identical
configurations and deliver the same functionality
to support a service or application. With a VM
scale set, it is possible to have the number of
virtual machines increase or decrease, adjusting
dynamically to changes in demand for the service
or application. To implement on demand auto-
scaling, you combine VM Scale Sets with Azure
Insights Autoscale.
VM Scale Sets integrate with Azure load balancers to efficiently handle dynamic distribution of network
traffic across multiple virtual machines. It also supports Network Address Translation (NAT) rules, allowing
for connectivity to individual virtual machines in the same scale set.
It is important to note that this solution differs from the IaaS v1 horizontal scaling approach, which
required that you to pre-provision any virtual machines you wanted to bring online to accommodate
increased demand.
Note: VM Scale Sets are available only when using the Azure Resource Manager
deployment model.
Implementing VM Scale Sets

You can implement VM scale sets by using an Azure Resource Manager template that provides
configuration details about their settings, including virtual machines, network adapters, virtual machine
extensions, load balancers, and Autoscale settings. To configure VM Scale Set-specific functionality,
reference the Microsoft.Compute/virtualMachineScaleSets resource type in the template. This resource
type implements a number of properties, including:
• sku.tier. The size of the virtual machines in the VM scale set.
• sku.capacity. The number of virtual machine instances that the scale set will auto-provision.
• properties.virtualMachineProfile. The disk, operating system, and network settings of the virtual
machines in the scale set.
To configure Autoscale, reference the Microsoft.Insights/autoscaleSettings resource type in an Azure

Resource Manager template. Some of the more relevant properties that this resource type implements
include:
• metricName. The name of the performance metric that determines whether to trigger horizontal
scaling (for example, Percentage CPU).
• metricResourceUri. The resource identifier designating the virtual machine scale set to monitor.
• timeGrain. The frequency with which performance metrics are collected (between 1 minute and 12
hours).
• Statistic. The method of calculating aggregate metrics from multiple virtual machines (Average,
Minimum, Maximum).
• timeWindow. Range of time for metrics calculation (between 5 minutes and 12 hours).
• timeAggregation. The method of calculating aggregate metrics over time (Average, Minimum,
Maximum, Last, Total, Count).
• Threshold. The value that triggers the scale action. For example, if you set it to 50 when using the
Percentage CPU metricName, the number of virtual machines in the set would increase when the CPU
usage exceeds 50 percent (specifics would depend on other parameters, such as statistics,
timeWindow, or timeAggregation).
• Operator. The criterion that determines the method of comparing collected metrics and the
threshold (Equals, NotEquals, GreaterThan, GreaterThanOrEqual, LessThan, LessThanOrEqual).
• Direction. The type of horizontal scaling invoked as the result of reaching the threshold (increase or
decrease, representing, respectively, scaling out or scaling in).
• Value. The number of virtual machines added to or removed from the scale set (one or more).
• Cooldown. The amount of time to wait since the most recent scaling event before the next action
occurs (from 1 minute to 1 week).
Additional Reading: For more information on virtual machine Scale sets, refer to
Automatically scale machines in a Virtual Machine Scale Set: http://aka.ms/C9gbgz.
Configuring virtual machine security

Microsoft Azure offers a number of technologies
that help to keep customer data secure in use,
in transit, and at rest. In this topic, you will learn
about the additional security measures that you
can implement by leveraging encryption
capabilities provided by Azure Key Vault that
apply to Azure IaaS virtual machine disk files
at rest.
Additional Reading: For more information

about Microsoft Azure general security practices,
refer to Security Features to help keep data safe:
http://aka.ms/Guhssp.
Understanding Key Vault

Key Vault serves as a store of cryptographic keys and secrets, such as storage account keys or passwords.
The vault maintains its content in encrypted form and offers the ability to further secure it by applying
hardware security module (HSM)-based protection.
A secret is essentially a small data blob (of up to 10 KB in size) that authorized users and applications can
retrieve from the vault. To secure access to secrets, you create Azure Active Directory objects representing
these users or applications, which they subsequently use to authenticate. Effectively, you avoid potential
risk associated with users storing secrets in nonsecure locations and eliminate the need to hard-code
them into applications.
Unlike secrets, keys stored in a vault do not leave its boundaries. Instead, once you add a key to the vault,
users and applications must invoke cryptographic functions to perform any operations that require its
knowledge. On the other hand, the ability to complete such invocation is also subject to a successful
Azure Active Directory-based authentication. To access keys and secrets, users and applications must
possess valid Azure Active Directory tokens representing security principal with sufficient permissions to
the target vault.
Every object residing in an Azure Key Vault has a unique identifier, which you must reference when
attempting to retrieve it (secret) or accessing it via a cryptographic function (key). In addition, you can
assign several additional attributes to both secrets and keys, which help with their retrieval and usage:
• exp. An expiration date of the secret, after which it is no longer possible to retrieve it from the vault.
• nbf. A date at which the secret becomes accessible.

• enabled. A Boolean value that determines whether the secret is accessible (assuming that the access
attempt takes place between the dates set by the values of the nbf and exp parameters).
Secrets also include the contentType attribute in the form of a string of up to 255 characters, which you
can use to describe their purpose.
Using Key Vault

You can use a REST-based API or Azure PowerShell to retrieve secrets and public parts of keys (in JSON
format) from Key Vault. In addition to performing the GET operation, you also have the ability to carry
out other management tasks targeting keys (create, import, update, delete, list, backup, or restore) and
secrets (set, list, or delete). Similarly, either of these two methods allow you to manage the vault and its
properties. Some of the most commonly used PowerShell cmdlets that facilitate interaction with an Azure
Key Vault include:
• New-AzureRmKeyVault creates a new Key Vault.

• Add-AzureKeyVaultKey creates a new—or imports an existing—key into a Key Vault.
• Get-AzureKeyVaultKey retrieves a public part of a key from a Key Vault.
• Get-AzureKeyVaultSecret retrieves a secret from a Key Vault.
• Remove-AzureKeyVaultKey remove a key from a Key Vault.
Additional Reading: For more information about Key Vault, refer to Get started with Azure
Key Vault: http://aka.ms/Wnz2hb.
Using Azure Disk Encryption

Azure Disk Encryption is a capability built into the Azure platform that allows you to encrypt file system
volumes residing on Windows and Linux IaaS v2 virtual machine disks. Azure Disk Encryption leverages
existing file system-based encryption technologies already available in the guest operating system
(BitLocker in Windows and DM-Crypt in Linux) to provide encryption of volumes hosting the operating
system and data. The solution integrates with Key Vault to securely store volume encryption keys.
Additionally, you also have the option to encrypt these keys by utilizing Key Encryption Key (KEK)
functionality of the vault. The combination of these features enhances security of Azure virtual machine
disks at rest by encrypting their content.
Note: It is possible to encrypt the data (but not the operating system) volumes of Azure
IaaS virtual machines running the Windows operating system by using BitLocker without relying
on Azure Disk Encryption. You also have the option of encrypting any volume (including the
operating system one) by implementing third-party solutions offered on Azure Marketplace, such
as CloudLink SecureVM.
There are three main scenarios in which you would use Azure Disk Encryption, all of them are applicable
to Azure Resource Manager deployments of standard A, D, and G series virtual machines:
• Enable encryption on new IaaS v2 virtual machines created from customer encrypted VHD and
corresponding encryption keys.
• Enable encryption on new IaaS v2 virtual machines created from the Azure Gallery.
• Enable encryption on existing IaaS v2 virtual machines already running in Azure.
Azure Disk Encryption is not supported for:
• Basic tier virtual machines.
• DS and GS series virtual machines (due to their support for Premium Storage disks).
• IaaS v1 virtual machines.
• Integration with on-premises Key Management Service.

• Linux virtual machines running Red Hat Enterprise Linux.
• Content of Azure Files (Azure file share), Network file system (NFS), dynamic volumes, and software-
based RAID configurations.
Azure Disk Encryption requires additional changes to obtain access to the Azure Key Vault where secrets
and encryption keys will reside. In particular, you must set the enabledForDiskEncryption property on
the vault to allow Azure platform to read BitLocker encryption keys and DM-Crypt passphrases from it.
When applying encryption to new or existing volumes, you also have to set up an Azure Active Directory
application with write permissions to the vault. This application provides a security context for Azure
platform, allowing it to securely store newly generated cryptographic material. In addition, you need to
configure the vault access policy to allow the Microsoft.Compute resource provider and Azure Resource
Manager to retrieve its secrets during virtual machine deployments.
Finally, you need to enable encryption on new or existing IaaS v2 virtual machines. Specifics of this last
step depend on which of the three scenarios you are implementing and which deployment methodology
you are using.
Additional Reading: For more information on Azure Disk Encryption, including how to
integrate it with Key Vault and configure it for VM deployment, refer to Azure Disk Encryption for
Windows and Linux IaaS VMs Preview: http://aka.ms/Jvkb03.
Demonstration: Configuring IaaS v2 virtual machine availability sets

In this demonstration, you will see how to create virtual machines in an availability set.
Demonstration Steps
1. On MIA-CL1, open Internet Explorer, and navigate to the Azure portal.
2. When prompted, sign in with an account that is either a Service Administrator or Co-Admin in the
subscription you are using for this demo.
3. From the Azure portal, create a new availability set with the following settings:
• Name: Demo4AVSet
• Fault domains: 3
Note: You can decrease the value to 2, but not increase it.
o Update domains: 5
Note: The number of update domains can vary between 5 and 20.
• Subscription: Your Azure subscription you intend to use for this demo.
• Resource group name: Demo4RG.
• Location: The Azure region closest to the location of your lab computer.
4. From the Azure portal, create a new virtual machine with the following settings:
• Name: Demo4VM1
• User name: Instructor
• Password: Pa$$w0rd
• Resource group: Demo4RG
• Location: The same location you chose for the availability set.
• Size: A1 Standard
• Disk type: Standard
• Storage account: Accept the default.
• Virtual network: Demo4RG
• Subnet: Accept the default.
• Public IP address: Demo4VM1
• Network security group: Demo4VM1

• Monitoring: Disabled
• Availability set: Demo4AVSet
• Name: Demo4VM2
• User name: Instructor
• Password: Pa$$w0rd
• Resource group: Demo4RG
• Location: The same location you chose for the availability set.
• Size: A1 Standard
• Disk type: Standard
• Storage account: Accept the default.

• Virtual network: Demo4RG
• Subnet: Accept the default.
• Public IP address: Demo4VM2

• Network security group: Demo4VM2
• Monitoring: Disabled
• Availability set: Demo4AVSet
6. From the Azure portal, display the blade of the Demo4AVSet availability set. On the Demo4AVSet
blade, note that the availability set contains the two newly deployed virtual machines (at this point,
both of them will likely display the Creating status). Point out that each VM has a unique fault
domain and update domain.

Question
What is the maximum number of update domains you can configure for an availability
set consisting of IaaS v2 VMs?
20
50
Lesson 2
Configuring virtual machine disks
Azure virtual machines use disks for different purposes, including operating systems, data, and temporary
storage. In this lesson, you will learn about the types of disks used by virtual machines, and how to
manage and configure these disks. You will also learn how to attach new and existing disks to virtual
machines, and how to use Storage Spaces within a virtual machine to configure multidisk volumes.
Lesson Objectives
• Describe virtual machine disks.
• Explain the different methods for managing virtual machine disks.
• Describe how to migrate virtual machine disks and images.
Overview of virtual machine disks

Disks that you attach to Azure virtual machines
are stored as Virtual Hard Disk (VHD) files within
an Azure storage account. A storage account is a
logical namespace capable of hosting four types
of objects: blobs, tables, queues, and files. You can
create a storage account by using variety of
methods, including the Azure portal, and Azure
PowerShell.
VHDs within storage accounts are stored as blobs.

Azure hosts two types of blobs—block blobs and
page blobs. Block blobs are typically used for
nonstructured, sequentially accessed files (such as
media content) of up to 200 gigabytes (GB). Page blobs take the form of files of up to 1 terabyte (TB) that
consist of 512-byte pages and are optimized for random read-write access.
Azure offers two tiers of storage accounts capable of storing VHD files—Standard and Premium.
Note: You will learn about Azure storage and its objects in details in Module 6: Planning
and implementing storage, backup, and recovery services of this course.
VHD files in an Azure storage account represent one of two object types—images or disks. Images serve
as templates from which you create new disks during provisioning of new virtual machines. There are two
types of images: operating system images and VM images. The former represents a single disk containing
a generalized installation of the Windows or Linux operating system. The latter refers to an image that
contains all disks attached to a VM during its capture.
To identify images, Azure Resource Manager provides a number of parameters, including:
• Publisher name. For example, MicrosoftWindowsServer
• Offer. WindowsServer
• SKU. For example, 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 disk:
o One per VM
o Maximum size of 1 TB
o Labeled as drive C
o Appears to VM as a SATA drive
• Temporary disk:
o One per VM
o The size varies depending on tier size used
o Labeled as drive D
o Provides temporary, nonpersistent storage (for example, page files)
• Data disks:
o Maximum number of disks is determined by the size of the VM

o Maximum size of 1 TB
o You can assign any available drive letter (starting with F:)
o Appears to VM as a SCSI drive

o Provides persistent storage for applications and data
Operating system and data disks are implemented as blob storage in a storage account. The temporary
disk is implemented as local storage on the Hyper-V host where the VM is running.
Using Storage accounts for virtual machine disks

Storage accounts provide the persistent store for virtual machine disks in Azure. When planning for virtual
machine disk configuration, you should note that charges related to the usage of storage are calculated
according to four criteria:
• Total amount of disk space represents the amount of storage you use (with Standard storage) or
allocate (with Premium storage).
• Replication topology determines how many copies of your data are concurrently maintained and the
number of Azure regions in which they are located.
• Transaction volume refers to the number of read and write operations performed against a storage
account.
• Data egress refers to data transferred out of an Azure region. When services or applications and the
storage account they are using are not located in the same Azure region, then typically, you will incur
charges for data egress. Note that this never applies to an Azure VM and blobs hosting its VHD-files,
because the storage account hosting these blobs must reside in the same region as the VM. However,
you should consider the location of an Azure VM in relation to other services that are part of your
Azure environment.
Managing virtual machine disks

When creating a virtual machine based on an
image, the Azure platform will automatically
provision a new operating system disk.
Alternatively, you have the option of attaching an
existing disk containing an operating system to a
newly created Azure virtual machine. This typically
happens when you migrate a virtual machine from
your on-premises environment to Azure. This is
discussed in more detail in the next topic.
Similarly, you can attach either new (empty or
image-based) or existing data disks to any Azure
virtual machine, up to the limit determined by
its size.
Attaching a virtual machine disk

To attach a disk to an Azure virtual machine, you can use the Azure portal or Azure PowerShell.
When using the Azure portal, take the following steps:
1. Navigate to the settings page for the virtual machine to which you are attaching the disk.
2. On the Settings page, click Disks, and then, on the Disks blade, click Attach new to create a new
virtual disk and attach it to the virtual machine, or click Attach existing to attach a .VHD file that is
stored in an Azure Storage account.
To attach a new empty virtual machine data disk by using Azure PowerShell, you would use the following
command:
Add-AzureRmVMDataDisk –ResourceGroupName <Resource Group name> –VM <VM object> -Name

<Disk name> -SourceImageUri <URI of the blob representing the disk in the storage
account> -CreateOption Empty –DiskSizeInGB <Disk size in GB>
Update-AzureRmVM –ResourceGroupName <Resource Group name> -Name <VM Name> -VM <VM object>
Detaching a virtual machine disk

To detach a virtual machine disk, you can use either the Azure portal or Azure PowerShell.
To detach a virtual machine disk using the Azure portal, use the following steps:
1. In the Azure portal, navigate to the Settings blade of the virtual machine from which you will detach
the disk, and then click Disks.
2. On the Disks blade, click the disk you want to remove and then, on the blade for that disk, click
Detach.
Note: You cannot detach the operating system disk.

To detach a disk using by using Azure PowerShell, use the following command:
Remove-AzureRmVMDataDisk –VM <VM object> -DataDiskNames <Disk name>

Update-AzureRmVM –ResourceGroupName <name> -Name <VM Name> -VM <VM object>
Note: You can use both Standard storage accounts and Premium storage accounts to store
virtual machine disks. However, only DS and GS series virtual machines can use virtual machine
disks that are stored in Premium storage accounts.
Modifying virtual machine disks

You can modify an existing Azure virtual machine disk configuration by:
• Changing caching mode of the disk.
• Increasing size of the disk (up to the 1 TB limit).
To modify a data disk, you should use the Set-AzureRmVMDataDisk cmdlet, followed by the
Update-AzureRmVM cmdlet.
Using Storage Spaces for Windows virtual machines

Starting with Windows Server 2012, you can use the Storage Spaces functionality to create multidisk
volumes. This capability offers several benefits:
• Improved performance, compared to individual disks or volumes configured by leveraging dynamic

disks (available in earlier versions of Windows).
• Three-way mirroring, offering higher resiliency than two-way mirror or parity configurations.
Considering that Azure storage is highly resilient by virtue of having three synchronously replicated
copies of the same content, this benefit does not offer a meaningful advantage in case of Azure
virtual machines.
• Support for volumes larger than 1 TB limit of a single disk size in Azure VMs.
To create a storage space in an Azure VM:
1. Create a new virtual machine running Windows Server 2012 or later. Avoid using lower tier VMs,
because they support fewer data disks.
2. Attach new, empty disks to the virtual machine.
3. Connect to the Windows operating system running in the virtual machine by using the Remote
Desktop Protocol (RDP) client.
4. Ensure that the File Server role service is installed.
5. Open the Server Manager, and navigate to File and Storage Services.
6. Click Storage Pools, and click Tasks.
7. Click New Storage Pool, and add the empty disks to the pool.
8. In File and Storage Services, select the pool, and then, in the Virtual Disks pane, click New Virtual
Disk.
9. Set the disk layout and size, and click Create.
10. The New Volume Wizard appears. Select the virtual disk you created, chose a drive letter, and then
create the volume.
Migrating virtual machine disks and images

Azure offers a straightforward approach to
integrating with your on-premises technologies.
One of the common scenarios that exemplify this
integration is migration of virtual machine disks
and images between the two environments.
When performing such migrations, you can use

the Azure PowerShell cmdlets Add-AzureVHD
and Save-AzureVHD to, respectively, upload and
download VHD files. In addition to performing the
data transfer, the cmdlets offer a number of extra
advantages:
• Add-AzureVHD will automatically convert

dynamic disks to fixed format to account for the fact that Azure does not support the former.
• Add-AzureVHD and Save-AzureVHD can inspect the .VHD file format and will only read/write
actual disk content and skip empty bytes, providing a more efficient data transfer experience.
• Both cmdlets support multithreading for increased throughput.
Migrating a virtual machine to Azure

The following code example illustrates how you can migrate a Windows Server 2012 R2 virtual machine
from an on-premises Hyper-V environment to the cloud by uploading its operating system disk and using
it to provision a new Azure virtual machine.
In this example, you will use an operating system disk of an on-premises virtual machine named VM1
running the Windows operating system. You will upload the .VHD file containing the operating system to
an Azure storage account and use it to provision a new Azure virtual machine named VM1 residing in the
RG1 resource group. The process will consist of the following steps:
1. Create an Azure storage account and a new container (named vhds) intended for storing VHD files:
$StorageAccountName = ‘storageaccount1’
$replicationType = ‘Standard_LRS’
$regionName = ‘East US’
$containerName = ‘vhds’
$resoruceGroupName = ‘RG1’
$VMName = ‘VM1’
$VMSize = ‘Standard_A1’
$VHDName = ‘VM1OSDisk’
$storageAccount = New-AzureRmStorageAccount –ResourceGroupName $resourceGroupName –
AccountName $storageAccountName –Location $regionName –Type $replicationType
$StorageAccountKey = Get-AzureStorageKey -StorageAccountName $StorageAccountName
$context = New-AzureStorageContext –StorageAccountName $StorageAccountName –
StorageAccountKey
New-AzureStorageContainer –Name $containerName –Context $context
2. Upload the VHD file to the storage account.
$sourceVHD = “D:\VHDs\$VHDName.vhd”
$destVHD =
“https://$storageAccountName.blob.core.windows.net/$containerName/$VHDName.vhd”
Add-AzureVHD –LocalFilePath $sourceVHD –Destination $destVHD
3. Create a new VM based on the VHD file uploaded to the Azure storage account.
$vm = New-AzureRmVMConfig –VMName $VMName -VMSize $VMSize

$vm = Set-AzureRmVMOSDisk –VM $vm -Name “$VHDName.vhd” –VhdUri $destVHD –CreateOption
Attach –Windows
NewAzureRmVM –ResourceGroupName $resourceGroupName –Location $regionName –VM $vm
Understanding the Azure import/export service

In addition to facilitating upload and download of VHD files, Azure also offers the Import/Export service.
The service accommodates transfers of larger amounts of data between on-premises locations and Azure
storage accounts, whenever its size makes it too expensive or not feasible to rely on network connectivity.
The process involves creating either import or export jobs, depending on the direction of transfer:
• You create an import job to copy data from your 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.

Question
You have an Azure VM running Windows Server 2012 R2 with a single data disk of 1 TB in
size. You need to create a file system volume of 3 TB in size. What should you do?
Attach two data disks. Create a Storage Spaces–based volume with the simple layout.
Increase the size of the data disk.
Attach one disk. Convert data disks to dynamic disks and create a stripe.
Attach two disks disk. Create a Storage Spaces–based volume with the parity layout.
Convert the disk to Premium storage and increase the size of the data disk.
Lesson 3
Managing and monitoring Azure virtual machines
Microsoft offers a number of different methods that simplify and enhance management of both Windows
and Linux operating systems hosted on Azure virtual machines. In this lesson, you will become familiar
with the most popular of these methods.
Lesson Objectives
• Identify configuration management options in Azure.
• Describe the VM Agent Custom Script extension.

• Describe the VM Agent Desired State Configuration extension.
• Explain how to monitor Azure virtual machines.
• Describe how to configure Desired State Configuration for an Azure IaaS v2 virtual machine.
Configuration management options

In general, you can categorize management
options for Azure VMs depending on the
operating system support they provide. While the
implementation details differ between the
Windows and Linux operating systems, some of
these options are (at least conceptually and, for
the most part, functionally) consistent across both
platforms.
Cross-platform management options

The first category of these options, cross-platform
management, is available across both Windows
and Linux platforms.
VM Agent and VM Agent Extensions

The VM Agent is a set of lightweight software components running within the operating system of an
Azure VM. Their primary purpose is to load additional programs and services known as VM Agent
Extensions, offered both by Microsoft and by its partners. VM Agent Extensions enhance Azure VM
functionality and manageability. In the Windows operating system, the agent takes the form of several
processes (WindowsAzureGuestAgent.exe, WaAppAgent.exe, and WindowsAzureTelemetryService.exe)
that collectively provide management, monitoring, and telemetry functionality. In the Linux operating
system, the agent is implemented as a waagent binary (/usr/sbin/waagent).
VM Agent is automatically included when you deploy an Azure VM by using the Image Gallery via
the Azure portal (according to the state of the Install the VM Agent check box, which is selected by
default). When using Azure PowerShell, you can control the VM Agent installation by leveraging the
–ProvisionVMAgent parameter of the Set-AzureRmVMOperatingSystem cmdlet. When using custom
images or disks, you have the option of installing the agent manually. Both the Windows and Linux
operating system versions of the VM Agent are available for download, from the Microsoft Downloads
and Github, respectively. After the installation completes, you also need to set the ProvisionGuestAgent
property of the virtual machine via Azure PowerShell or a REST API call.
VM Agent Extensions are covered in more details later in this lesson.
Azure cross-platform command-line interface

The Azure cross-platform command-line interface (Azure CLI) is an open source implementation of a set
of shell-based commands allowing you to manage a variety of Azure resources. You can install it on
Windows, Linux, and Macintosh platforms, and run against both Linux-and Windows based Azure VMs.
Azure PowerShell
Azure PowerShell is an open source Windows PowerShell module that provides management capabilities
equivalent to those offered by Azure CLI. Just like Azure CLI, it allows you to interact with Azure virtual
machines running both the Windows and Linux operating systems, however, you have to install it on and
run it from a computer running the Windows operating system. The two command line management
interfaces (Azure PowerShell and Azure CLI) offer, for the most part, feature parity, although occasionally
you might find one of them providing more functionality than the other.
Platform-specific management options

Some of the management options are operating system-specific.
RDP
RDP allows for establishing a graphical user interface session to an Azure virtual machine running the
Windows operating system. When viewing a Windows virtual machine in the Azure portal, you will have
access to the Connect action. This action automatically provisions an .rdp file, which you can either open
or download, and save for later use. Opening the file initiates an RDP connection to the corresponding
VM. The Azure PowerShell Get-AzureRemoteDesktopFile cmdlet delivers the same outcome when you
invoke it via a command line.
Secure Shell
When creating a Linux VM, you have the option to enable Secure Shell (SSH). At that point, you can
establish a connection to this VM by using the SSH protocol from a terminal emulator, such as PuTTY
(available for both Windows and Linux operating systems).
Note: While it is possible to install a third-party SSH server on the Windows operating
system (effectively allowing connecting to it from an SSH client, such as PuTTY), this option is not
available directly when deploying Azure virtual machines.
What is the VM Agent Custom Script extension?

The Custom Script extension for Azure virtual
machines enables you to invoke local execution of
scripts within a Windows or Linux Azure virtual
machine. On the Windows operating system, you
can implement scripts by using Windows
PowerShell. The extension for the Linux operating
system allows running code written in any
scripting language supported by the operating
system, such as Python or Bash.
The most common use of Custom Script extension

involves applying custom configuration settings
during VM provisioning; however, it is also
possible to use it to perform any scriptable action after the initial deployment. The script can reside in an
Azure storage account or a Github location.
Configuring the Custom Script extension

To configure the functionality described in this topic, you need to install the Customs Script extension in
the operating system hosted on an Azure VM that you intend to manage, and assign the script that you
want the extension to execute. You can accomplish this either during VM provisioning or afterwards by
running the Set-AzureRmVMCustomScriptExtension PowerShell cmdlet.
Set-AzureRmVMCustomScriptExtension -ResourceGroupName <Resource Group name> -Location

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

$protectedSettings = @{“storageAccountName = <Storage account name>; “storageAccountKey”
= <Storage account key>};
Set-AzureRmVMExtension -ResourceGroupName <Resource Group name> -Location <Azure region>
-VMName <VM name> -Name <Custom Script extension name> –Publisher “Microsoft.Compute”
–ExtensionType “CustomScriptExtension” -TypeHandlerVersion "1.4" –Settings $settings
–ProtectedSettings $protectedSettings
The cmdlet is in many aspects similar to Set-AzureRmVMCustomScriptExtension. For example, it also

uniquely identifies the target Azure virtual machine by using the combination of -ResourceGroupName,
-Location, and -VMName. On the other hand, it relies on the two hashtables to point to the location and
execution settings of the custom script. Due to its more generic purpose, it also includes direct references
to the extension that you intend to apply in the form of the -Publisher, -ExtensionType, and
-TypeHandlerVersion parameters.
Note: When applying scripts to Azure virtual machines running the Linux operating system,
you would set the -Publisher parameter to Microsoft.OSTCExtension and the -ExtensionType
parameter to CustomScriptForLinux.
Using Custom Script extension with Resource Manager templates

Another approach to deploying Custom Script extension leverages Resource Manager templates. The
imperative (based on the Set-AzureRmExtension cmdlet) and declarative (based on the Azure Resource
Manager template presented here) methods are compatible with each other, allowing you to deploy the
same types of scripts and supporting the same set of parameters (although with templates, you have to
specify the exact version of the handler, while with scripts, you have the option to use the majorversion.*
format). The following template illustrates this premise, showing you how to apply a script named
script1.ps1 to an Azure virtual machine identified by the vmName and location parameters:
{
"type": "Microsoft.Compute/virtualMachines/extensions",
"name": "MyCustomScriptExtension",
"apiVersion": "2015-05-01-preview",
"location": "[parameters('location')]",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/',parameters('vmName'))]"
],
"properties": {
"publisher": "Microsoft.Compute",
"type": "CustomScriptExtension",
"typeHandlerVersion": "1.4",
"settings": {
"fileUris": [
"http://storageaccountname.blob.core.windows.net/customscriptfiles/script.ps1"
],
"commandToExecute": "powershell.exe -ExecutionPolicy Unrestricted -File
script.ps1"
}
}
}
Additional Reading: For more information on using Custom script extensions with Azure
virtual machines, refer to Using Custom Script extension with Azure Resource Manager templates:
http://aka.ms/Azasu4.
What is the VM Agent Desired State Configuration extension?

PowerShell Desired State Configuration (DSC) is a
technology introduced in Windows Management
Framework 4.0 that implements template-based
configuration of Windows and Linux operating
systems, both on-premises and in the cloud. Due
to its declarative nature, it bears some
resemblance to Azure Resource Manager,
however, while Azure Resource Manager
templates deploy Azure resources such as VMs,
DSC targets operating systems running within
these VMs.
In general, DSC leverages functionality

incorporated into Windows Management Framework, however, in case of Azure VMs, this functionality is
implemented as a dedicated VM Agent extension, known as Desired State Configuration extension. When
managing Azure IaaS v2 VMs, you can use Azure Resource Manager templates to apply DSC to Azure VMs
by referencing this extension.
DSC relies on the component known as Local Configuration Manager (LCM), which serves as the
execution engine of the DSC PowerShell scripts. LCM is responsible for coordinating implementation of
DSC settings and monitoring their ongoing status. LCM (just as DSC) is an integral part of Windows Server
2012 R2 and Windows Server 2016. It is also available for Windows Server 2008 R2 as part of the Windows
Management Framework download. The DSC LCM ConfigurationMode property takes on one of three
possible values, which determine how LCM handles DSC PowerShell scripts:
• ApplyOnly. LCM executes the script only once.
• ApplyAndMonitor. LCM executes the script only once, but monitors the resulting configuration
afterwards and records any configuration drift in logs.
• ApplyAndAutoCorrect. LCM executes the script in regular intervals, automatically correcting any
configuration drift.
DSC relies on small, dedicated pieces of code known as DSC resources to handle resource-specific
implementation details. In this context, the term “resource” means any configurable software component,
such as a file, folder, registry, service, or an operating system feature. DSC includes with a number of built-
in resources, but it is extensible, making its management scope virtually unlimited.
You can deploy DSC configuration in one of two modes, push mode, and pull mode. The push mode
involves invoking deployment from a management computer against one or more managed computers.
In the pull mode managed computers act independently by obtaining configuration data from a
designated location (referred to as a Pull Server). You will focus here on the push mode. You will revisit
the pull mode in the Implementing Azure-based management and automation module of this course,
when describing its role in the context of Azure Automation.
Creating Windows DSC Configuration scripts

DSC scripts utilize syntax (enclosed in the configuration construct) introduced in Windows PowerShell
v 4.0 (included in Windows Management Framework 4.0) to define the intended operating system
configuration.
Note: In general, it is necessary to convert Windows PowerShell DSC scripts into the
Management Object Format (MOF) node configuration files by compiling them using Windows
PowerShell cmdlets. However, Azure PowerShell handles the compilation automatically when
deploying DSC extensions to Azure VMs running the Windows operating system.
For example, the following .ps1 file instructs the LCM running on the local computer to install the Internet
Information Services (IIS) server role, the .NET ASP 4.5 feature, and disable the default website. Note that
the task to disable the default website is facilitated by a custom DCS resource, which you import by
adding the Import-DscResource cmdlet. In addition, as you can easily deduct from the presence of the
DependsOn element, you have the ability to control the sequence of task execution by defining
dependencies between them.
configuration IISConfig
{
Import-DscResource –Module xWebAdministration
node ("localhost") {
WindowsFeature IIS {
Ensure = "Present"
Name = "Web-Server"
}
WindowsFeature AspNet45 {
Ensure = "Present"
Name = "Web-Asp-Net45"
}
xWebsite DefaultSite {
Ensure = "Present"
Name = "Default Web Site"
State = "Stopped"
PhysicalPath = “C:\inetpub\wwwroot"
DependsOn = "[WindowsFeature]IIS"
}
}
}
Implementing DSC in Azure IaaS v2 Windows VMs

Applying Desired State Configuration to an Azure IaaS v2 virtual machine running Windows involves a
sequence of the following steps:
1. Sign in to your Azure subscription by using the Add-AzureRmAccount cmdlet. If you have multiple
subscriptions associated with the same account, ensure you select the target one by using the
Set-AzureRmContext cmdlet.
Add-AzureRmAccount
2. Publish Azure DSC configuration to an Azure storage account by running the Publish-
AzureRmVMDscConfiguration cmdlet. The configuration (the -ConfigurationPath parameter)
takes the form of a Windows PowerShell script (a .ps1 file, like the one listed in the previous section),
a PowerShell module (a .psm1 file), or an archive containing a combination of scripts, modules, and
resources (a .zip file). The -ResourceGroupName, -StorageAccountName, and -ContainerName
parameters designate the storage account blob container where the configuration will reside.
$moduleURL = Publish-AzureRmVMDscConfiguration -ConfigurationPath <File system path

of the configuration script> -ResourceGroupName <Name of resource group hosting the
storage account> -StorageAccountName <Storage account name> –ContainerName <Blob
container name >
The publishing process will first generate a .zip file containing all scripts, modules, and resources
referenced by the configuration and then upload this archive into the Azure storage location you
specified.
3. Create a shared access signature token that will provide access to the archive configuration file
residing in the Azure storage account. A shared access signature is a digitally-signed string that
identifies an Azure storage objects and determines access permissions to that object. In this case,
Read permissions will suffice. To create a shared access signature token, you first need to establish the
security context for access to the target Azure storage account. To establish such context, you need to
provide the storage account name and storage account key (which you can retrieve from the Azure
portal or by using Azure PowerShell).
$storageContext = New-AzureStorageContext –StorageAccountName <Storage account name>

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

<VM name> -Location <Azure region> -Name ‘DSC’ -Publisher ‘Microsoft.PowerShell’ `
-ExtensionType ‘DSC’ -TypeHandlerVersion ‘2.0’ -Settings $settingsHashTable
Alternatively, as with Custom Script extension, you have the option of using the extension-specific
Azure PowerShell cmdlet Set-AzureRmVMDscExtension.
Additional Reading: For more information, refer to Set-AzureRmVMDscExtension:

http://aka.ms/Cyyypz.
Note: As with Custom Script extension scripts, you can reference DSC configuration files
residing either in an Azure storage account or a Github location.
Alternatively, you have the option of deploying the DSC configuration by using the Azure Resource
Manager templates.
Additional Reading: For more information on deploying DSC configuration by using

Azure Resource Manager templates, refer to Developing DSC scripts for the Azure Resource
Manager DSC Extension: http://aka.ms/Er0zdg.
Implementing the AzureDSCForLinux extension

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

-ResourceGroupName, -VMName, and -Location parameters identify the target Azure
virtual machine. The -Name, -Publisher, -ExtensionType, and -TypeHandlerVersion parameters
designate the intended VM Agent extension.
Set-AzureRmVMExtension -ResourceGroupName <Resource group name -VMName <VM name> `

-Location <Azure region> -Name ‘DSCForLinux’ -Publisher 'Microsoft.OSTCExtensions'`
-ExtensionType ‘DSCForLinux’ -TypeHandlerVersion ‘1.0’ -SettingString $settings `
-ProtectedSettingString $protectedSettings
Monitoring Azure virtual machines

Azure IaaS virtual machines, just like the majority
of Azure services, provide the ability to track their
performance, availability, usage, and health. This
functionality is exposed directly in the Azure
portal. In addition, it is also possible to manage
monitoring programmatically via the REST API
and .NET SDK.
Enabling metrics and diagnostics

You can enable and configure a collection of
metrics and diagnostics for an Azure IaaS VM
from its Monitoring lens in the Azure portal By
clicking any of the tiles, you will be automatically redirected to the Diagnostics blade. From here, you
need to specify an Azure storage account that will host collected data, and then decide which metrics and
diagnostics you intend to collect. Below is a list of metrics and diagnostics that you can collect:
• Basic metrics
• Network metrics
• .NET metrics
• ASP.NET metrics
• SQL metrics
• Windows event system logs (including type of events and their verbosity level)
• Windows event security logs (including type of events and their verbosity level)
• Windows event application logs (including type of events and their verbosity level)
• Diagnostics infrastructure logs (including type of events and their verbosity level)
• IIS logs
• Boot diagnostics (providing console output and screenshot support for Azure IaaS v2 VMs)
The ability to collect diagnostics requires presence of VM Agent Diagnostics extension (IaaSDiagnostics),
available for IaaS VMs running either the Windows or the Linux operating systems.
Working with metrics and diagnostics data

The Azure portal displays charts of the metrics representing performance and usage for each monitored
VM. You can edit and modify any of these charts by right-clicking them and clicking Edit Chart in the
context-sensitive menu. This opens the Edit Chart blade where you have the option of modifying the time
range and the chart type, as well as adding other metrics.
To view and analyze diagnostics and logs not available directly from the portal, you can use any tools that
provide access to tables and blobs in the Azure storage account hosting collected data. You have the
option to export it into Excel or any Business intelligence application (such as Azure BI) for further analysis.
Alerts
Alert rules allow you to trigger notifications according to metrics-based criteria you specify. Each rule
includes a metric, condition, threshold, and time period that collectively determine when to raise an alert.
You have the option of sending an email containing the alert notification to any email address. In
addition, it is also possible to route alerts to an arbitrary HTTP or HTTPS endpoint (which the Azure portal
interface references as a Webhook). You should keep in mind that there is a limit of 250 alerts per
subscription.
Demonstration: Configuring IaaS v2 Windows virtual machines with DSC

In this demonstration, you will see how to apply DSC to an Azure virtual machine running the Windows
operating system.
Demonstration Steps
1. On MIA-CL1, start File Explorer and browse to D:\Demofiles\Mod04.
2. In the D:\Demofiles\Mod04 folder, right-click on the IISInstall.ps1 file and select Edit from the
right-click menu. This will open the file in the Windows PowerShell ISE.
3. Review the content of the file. Note that this is a DSC configuration that controls the installation of
the Windows Server 2012 R2 Web-Server role.
4. Close the PowerShell ISE window.

5. In the File Explorer, right click on the D:\Demofiles\Mod04\DeployAzureDSC.ps1 file and select
Edit from the right-click menu. This will open the file in the Windows PowerShell ISE.
6. Review the content of the script. Note the variables it uses, including the storage account and its key.
Note that it first publishes the DSC configuration defined in the Install.ps1 file to the same storage
account hosting the VHD files of the two virtual machines (placing it in the default DSC container
named windows-powershell-dsc), stores the resulting module URL in a variable, and then sets the
Azure Agent VM DSC extension on two virtual machines deployed in the previous demonstration by
referencing that URL. The script generates a shared access signature token that provides read only
access to the blob representing the DSC configuration archive.
7. Start the execution of the script. When prompted, sign in with the username and the password of an
account that is either a Service Administrator or a Co-Admin of your Azure subscription. Wait until
the script completes.
8. On MIA-CL1, open Internet Explorer, and then navigate to the Azure portal.
9. Initiate a Remote Desktop session to Demo4VM1 from the Azure portal.
10. When prompted to enter credentials to connect, type Instructor as the user name, and Pa$$w0rd as
the password.
11. After you establish Remote Desktop session to the VM, in the Server Manager window, verify that IIS
appears in the left pane, indicating that the Web Server (IIS) server role is installed.
12. Repeat steps 7 through 9 for the Demo4VM2 virtual machine.
13. Open Windows PowerShell as an administrator.
14. At the Windows PowerShell command prompt, run the following command:
Reset-Azure
15. When prompted (twice), sign in by using the Microsoft account that is associated with your Azure
subscription.
16. If you have multiple Azure subscriptions, select the one that you want to target with the script.
17. When prompted for confirmation, press Y.
Note: This script will remove Azure services in your subscription. We therefore
recommended that you use an Azure trial pass that was provisioned specifically for this course,
and not your own Azure account.
The script will take 5-10 minutes to reset your Azure environment, ready for the next lab.
The script removes all storage, virtual machines, virtual networks, cloud services, and resource
groups.
Important: The script might not be able to access a storage account to delete it (if this occurs,
you will see an error). If you find objects remaining after the reset script is complete, you can
rerun the Reset-Azure script, or you can use the Azure portal and the Azure classic portal to
delete all the objects in your Azure subscription manually—with the exception of the default
directory.

Question
You plan to capture an image of your on-premises Windows Server 2012 R2 virtual machine
to Azure and use it to deploy Azure virtual machines that will be managed by leveraging
DSC. What should you do prior to capturing the image?
On the Windows Server 2012 R2 VM, install Azure VM Agent.
On the Windows Server 2012 R2 VM, install Windows Management Framework.
On the Windows Server 2012 R2 VM, install Azure PowerShell module.
Run sysprep with the specialize option.
Run sysprep with the mode:vm option.

Lesson 4
Managing IaaS v1 virtual machines
The first three lessons of this module focused on managing and monitoring IaaS v2 virtual machines.
However, it is likely that your future experiences with Azure services will involve administering IaaS v1
virtual machines as well. While they share a number of common characteristics, there are also some
important differences between them of which you should be aware. In this lesson, you will learn about
some of these differences.
Lesson Objectives
• Identify the primary differences in configuring Azure IaaS v1 and IaaS v2 virtual machines.
• Describe how to managing disks and images of IaaS v1 virtual machines.
• Explain how to monitor IaaS v1 virtual machines.
Configuring IaaS v1 virtual machines

One of the main distinguishing characteristics of
IaaS v1 virtual machines—in comparison with IaaS
v2—is their inherent dependency on cloud
services. Any VM you create by using the Service
Management deployment model becomes part of
a new or an existing cloud service. A cloud service
constitutes a logical boundary for virtual machines
it contains, offering a number of additional
features, including:
• A public IP address and associated Domain

Name System (DNS) name in the
cloudapp.net DNS namespace.
• Support for endpoints, which you can use to expose individual ports of VMs within the cloud service
for external access (from the Internet or other Azure services).
• Automatic name resolution and direct communication between its VMs without the need to use their
fully qualified domain names (FQDNs).
• Automatic assignment of private IP addresses to its VMs.
In addition to being part of a cloud service—which is mandatory in the Service Management model—
a virtual machine can also belong to a virtual network. By implementing this approach, you allow for
direct communication between VMs in different cloud services, as long as they are on the same virtual
network or on virtual networks connected to each other.
To deploy an IaaS v1 VM into a virtual network, you must implement that virtual network by using Service
Management. In other words, IaaS v1 VMs require an IaaS v1 VNet and, conversely, IaaS v1 VNets support
only IaaS v1 VMs.
While the network model changed significantly in Azure Resource Manager, the VNet IP addressing rules
remain the same. This means that you can follow the VNet design guidelines provided in earlier modules
of this course. On the other hand, remember that network implementation rules have changed in Azure
Resource Manager (for a detailed discussion, refer to the Implementing and managing Azure networking
module).
In addition, note that external connectivity to IaaS v1 VMs generally (with the exception of instance-level
IP addresses, which are described next) relies on cloud service endpoints. Because IaaS v2 does not
support cloud services, you will not be able to leverage topics applicable to Azure Resource Manager–
based implementations, but instead, follow the information provided here.
An endpoint allows access to a VM residing in a cloud service via its public IP address, either TCP or UDP
protocol, and an arbitrary public port, which maps to a designated internal port of the VM. By default,
provisioning a Windows-IaaS v1 VM automatically creates a Remote Desktop Protocol (RDP) and a
Windows Remote Management (WinRM) endpoint. Similarly, provisioning a Linux- VM results in the
creation of a Secure Shell (SSH) endpoint. You have the option of disabling any of them at the time of
deploying the virtual machine or at any point afterwards. Keep in mind that disabling the endpoint affects
only external connectivity, still allowing you to connect to the virtual machine from within the same cloud
service or virtual network.
You can also create arbitrary endpoints for VMs. Endpoint can be configured as part of a load-balanced
set, to provide traffic distribution across multiple VMs. It can also be configured for direct server return.
This provides the VM endpoint the floating IP capability necessary to set up a SQL AlwaysOn Availability
Group.
Instance-level Public IP addresses

If you want to be able to connect to a VM from outside the cloud service by an IP address assigned
directly to it, rather than by using the cloud service VIP:<portnumber>, you can use instance-level
Public IP (PIP) addressing.
Typical usage scenarios for PIPs include:
• Passive FTP. Using a PIP, the VM can receive traffic on any port. This enables scenarios such as passive
FTP where the ports are chosen dynamically.
• Outbound IP. Outbound traffic originating from the VM uses PIP as the source, which uniquely
identifies the VM to external entities.
Azure Load Balancing

Azure Load Balancing for IaaS v1 virtual machines also relies on the capabilities inherent to cloud services.
To configure Azure load balancing across VMs in a cloud service, you must create the load-balanced set,
and in this set include all of the VMs (within the same cloud service) that you want to respond to external
requests to a particular public IP address and port number. These VMs listen on their private IP address
and private port; the Azure Load Balancer, therefore, maps the public IP address and port number of the
cloud service to the private IP address and port number of one VM in the set, and reverses this for the
response traffic from the VM.
Direct Server Return

One potential issue with Azure load balancing is the possibility of the load balancer to become a
bottleneck if the volume of traffic is high. To remediate this issue, you can configure a load-balanced set
to provide Direct Server Return. This feature allows the VM that is servicing a client request to respond
directly to the client. Effectively, the load balancer is free to handle new requests, rather than keep
processing responses. Direct Server Return is commonly implemented for video or audio, which are
susceptible to network delays.
Availability sets
Another IaaS v1 VM feature that relies on the existence of cloud services is the availability set. In this
context, an availability set represents a logical grouping of virtual machines that belong to the same cloud
service. Just as with IaaS v2 VM–based availability set, each virtual machine in the same availability set is
automatically assigned a distinct Update Domain (up to two) and a Fault Domain (up to five).
Access Control List
A cloud service facilitates protection of its endpoints by allowing you to associate them with Access
Control Lists (ACLs). An ACL contains a range of external IP addresses for which the access should be
either explicitly permitted or denied. However, the functionality provided by ACLs has been superseded
by Network Security Group, which you can use to control not only external but also internal (within a
virtual network) traffic, so at this point, there is no compelling reason to use them anymore.
Managing and configuring IaaS v1 VM storage

In general, the concepts applicable to managing
disks and images of IaaS v1 virtual machines have
not changed significantly with transition to the
Azure Resource Manager model. However, there
are a few important differences that you must
consider:
• IaaS v1 VMs require an IaaS v1 Azure storage

account to host their disks. Similarly, you
cannot deploy an IaaS v1 VM by using an
image hosted in an IaaS v2 Azure storage
account.
• To identify IaaS v1 VM images, you need to

reference them by the name of the corresponding VHD file. This changed with the Azure Resource
Manager model (for details, refer to the second lesson of this module).
Command line management of IaaS v1 VM disks also differs from managing their IaaS v2 counterparts,
because they use a different set of Azure PowerShell cmdlets. Starting with Azure PowerShell 1.0, Azure
Resource Manager-cmdlets use the -AzureRm substring in place of the -Azure substring present in
the Service Management cmdlets. For example, to add a data disk to an IaaS v1 VM, you would use
Add-AzureVMDataDisk, but to apply the same change to an IaaS v2 VM, you would run
Add-AzureRmVMDataDisk.
Monitoring and managing IaaS v1 VMs

Monitoring options of IaaS v1 VMs do not differ
significantly from the functionality available to
IaaS v2 VMs. The same capabilities are exposed in
the Azure portal, including metrics, diagnostics,
and alerting. The only exception is support for
boot diagnostics (providing console output and
screenshot support) that depend on Azure
Resource Manager.
As far as operating system management is

concerned, while both Azure Resource Manager
and Service Management provide matching
features in this area, the implementation details of
each are different. This is primarily due to the different set of supporting Windows PowerShell cmdlets
and lack of support for template-based deployments for IaaS v1 VMs. In addition, Service Management-
based Azure PowerShell scripts are relatively simpler, allowing you, for example, to leverage default
storage account of your Azure subscription for storing Custom Script extension scripts or DSC
configuration archives.
It is important to note that, just as with IaaS v2 VMs, both Custom Script extension and Desired State
Configuration–based management are available for IaaS v1 VMs running both the Windows and Linux
operating systems.
Additional Reading: For more information on implementing custom script extension in

the classic deployment model, refer to Custom Script extension for Windows virtual machines:
http://aka.ms/Pcv1if.

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

Lab: Managing Azure virtual machines

Scenario
Now that you identified basic deployment options of IaaS v2 VMs, you need to start testing more
advanced configuration features. As part of these tests, you need to place the two web servers, which will
host the A. Datum ResDev application, in a load-balanced availability set. You will also install IIS on these
virtual machines by using the VM Agent DSC extension. In addition, to enhance Azure IaaS virtual
machine storage, you will set up Storage Spaces–based volumes.
Objectives
• Configure Azure virtual machine availability.
• Implement desired state configuration in Azure virtual machines.
• Implement Storage Space–based simple volumes in Azure virtual machines.
Lab Setup
Virtual Machine: 20533C-MIA-CL1
User name: Student
Password: Pa$$w0rd
Exercise 1: Configuring availability

Scenario
You need to redeploy the ResDev app to leverage Azure availability capabilities. You will start by
provisioning ResDevWebVM1 and ResDevWebVM2 Azure IaaS v2 VMs into an availability set named
ResDevWebAS. Next, you will create an Azure load balancer and add both virtual machines to its backend
pool.

1. Create virtual machines in an availability set.
2. Configure the Azure Load Balancer.
 Task 1: Create virtual machines in an availability set

1. On MIA-CL1, open Internet Explorer and navigate to the Azure portal.
subscription you are using for this lab.
3. From the Azure portal, create a new availability set with the following settings:
o Name: ResDevWebAS
o Fault domains: 3
o Update domains: 5
o Subscription: Your Azure subscription you intend to use for this demo.
o Resource group name: ResDevWebAS
o Location: The Azure region closest to the location of your lab computer.
o Name: ResDevWebVM1
o Resource group: ResDevWebAS

o Location: The same location you chose for the availability set.
o Size: A1 Standard
o Disk type: Standard
o Storage account: Accept the default.
o Virtual network: ResDevWebAS
o Subnet: Accept the default.

o Public IP address: ResDevWebVM1
o Network security group: ResDevWebVM1
o Monitoring: Disabled
o Availability set: ResDevWebAS
o Size: A1 Standard

6. From the Azure portal, display the blade of the ResDevWebAS availability set. On the Demo4AVSet
blade, note that the availability set contains the two newly deployed virtual machines (at this point,
both of them will likely display the Creating status). Point out that each VM has a unique fault
domain and update domain.
7. Leave the instance of Internet Explorer with the Azure portal open.
 Task 2: Configure the Azure Load Balancer

1. On MIA-CL1, in the Azure portal within the Internet Explorer window, create a new load balancer with
the following settings:
o Name: ResDevWebLB
o Scheme: Public
o Public IP address: Create a new dynamic address named ResDevWebLBIP.

o Pin to dashboard: Unchecked

2. Wait for the deployment to complete. This should take a few seconds.
3. From the Azure portal, add a backend pool named ResDevWebLBPool to the newly created load
balancer consisting of the ResDevWebAS availability set and both virtual machines that are part of it
(ResDevWebVM1 and ResDevWebVM2).
4. Add a probe to the load balancer with the following settings:
o Name: ResDevWebProbe80
o Protocol: HTTP
o Port: 80
o Path: /
o Interval: 5
o Unhealthy threshold: 2
5. Add a load balancer rule to the newly created load balancer with the following settings:
o Name: ResDevWebLBRule80
o Protocol: TCP
o Port: 80
o Backend Pool: ResDevWebPool
o Probe: ResDevWebProbe
o Backend port: 80
o Session persistence: None
o Idle timeout: 4
o Floating IP: Disabled
6. Refresh the Azure portal. In the Setting blade of ResDevWebLB, you should be able to identify its
public IP address. Note that at this point you will not be able to connect to the two virtual machines
in the backend pool, because they are not running a web server and the connectivity is additionally
restricted by default network security group settings. You will change these settings later in this lab.
Results: After completing this exercise, you should have created an availability set for Azure IaaS v2 virtual
machines and configured them up as a load balanced pair.
Exercise 2: Implementing DSC

Scenario
You need to test the implementation of the desired state configuration in Azure by using VM Agent DSC
extension to install the default IIS Web site on both virtual machines that will host the A. Datum ResDev
application. Once the installation is complete, you must test the availability of this setup by verifying that
load balanced access to the default Web site is not affected by shutting down one of the virtual machines.

1. Install and configure IIS by using DSC and Windows PowerShell.
2. Test the DSC configuration and virtual machine availability.
 Task 1: Install and configure IIS by using DSC and Windows PowerShell
1. On MIA-CL1, start File Explorer and browse to the D:\Labfiles\Lab04\Starter folder.
2. In the D:\Labofiles\Lab04 folder, right-click on the IISInstall.ps1 file and select Edit from the right-
click menu. This will open the file in the Windows PowerShell ISE.
4. Close the Windows PowerShell ISE window.
5. In the File Explorer, right click on the D:\Labfiles\Lab04\Starter\DeployAzureDSC.ps1 file and

select Edit from the right-click menu. This will open the file in the Windows PowerShell ISE window.
6. Review the content of the script. Note the variables that it uses, including the storage account and its
key. The script first publishes the DSC configuration defined in the Install.ps1 file to the same storage
Azure Agent VM DSC extension on two virtual machines deployed in the previous lab by referencing
that URL. The script generates a shared access signature token that provides read only access to the
blob representing the DSC configuration archive.
8. On MIA-CL1, open Internet Explorer and navigate to the Azure portal.

9. Initiate a Remote Desktop session to ResDevWebVM1 from the Azure portal.
10. When prompted to enter credentials to connect, type Student as the user name and Pa$$w0rd as
the password.
11. Once you establish a Remote Desktop session to the VM, in the Server Manager window, verify that
IIS appears in the left pane, indicating that the Web Server (IIS) server role is installed.
12. Repeat steps 7 through 9 for the other virtual machine, ResDevWebVM2.
13. After completing the tasks, switch back to your lab computer MIA-CL1. Leave both Remote Desktop
sessions open.
 Task 2: Test the DSC configuration and virtual machine availability

1. From the Azure portal within the Internet Explorer window on MIA-CL1, create a new inbound
security rule for the ResDevWebVM1 security group with the following settings:
o Name: allow-http
o Priority: 1100
o Source: Any
o Protocol: TCP
o Destination: Any
o Destination port range: 80
o Action: Allow
2. From the Azure portal within the Internet Explorer window on MIA-CL1, create a new inbound
security rule for the ResDevWebVM2 security group with the following settings:
o Name: allow-http
o Priority: 1100
o Source: Any
o Protocol: TCP
o Destination: Any
o Action: Allow
3. From the Azure portal, identify the IP address of the ResDevWebLB load balancer.
4. From MIA-CL1, open a new InPrivate Browsing Internet Explorer session and browse to this IP
address.
5. Verify that you can access the default IIS webpage and close the InPrivate Browsing session.
6. From the Remote Desktop session window, stop the World Wide Web Publishing Service service on
both ResDevWebVM1 and ResDevWebVM2.
7. From MIA-CL1, open a new InPrivate Browsing Internet Explorer session.
8. In the new InPrivate Browsing window, delete the browsing history.
9. Browse to the IP address of the ResDevWebLB load balancer again and verify that you can no longer
access the default IIS webpage.
10. From the Remote Desktop session window, start the World Wide Web Publishing Service service on
ResDevWebVM1.
11. Once the service is running, switch back to MIA-CL1 and refresh the InPrivate Browsing Internet
Explorer window. Verify that you can again access the default the default IIS webpage.
Note: Optionally you can repeat this sequence, but this time stopping the World Wide
Web Publishing Service on ResDevWebVM1 and starting it on ResDevWebVM2. As long as the
service is running on at least one of the two virtual machines, you should be able to access the
webpage.
Results: After completing this exercise, you should have implemented DSC.
Exercise 3: Implementing Storage Space–based volumes

Scenario
To test enhanced storage configuration of the virtual machines that will host the A. Datum ResDev
application, you need to create three new virtual machine disks, attach them to one of the virtual
machines, and create a Storage Spaces volume on the virtual machine.
1. Attach VHDs to an Azure VM.

2. Configure a Storage Spaces simple volume.
 Task 1: Attach VHDs to an Azure VM

1. On MIA-CL1, from the Azure portal in the Internet Explorer window, attach two data disks to the
ResDevWebVM1 virtual machine with the following settings:
o Name: Accept the default
o Type: Standard
o Size: 1023
o Location: Note that this cannot be changed since the location of the VM determines the
location of its disks.
o Host caching: None
2. Note that with current VM size (Standard A1), there is a limit of 2 data disks per VM.
 Task 2: Configure a Storage Spaces simple volume

1. On MIA-CL1, switch to the Remote Desktop session to ResDevWebVM1.
2. While connected to ResDevWebVM1, from the Server Manager window, create a storage pool named
StoragePool1 consisting of two newly attached disks.
3. From the Server Manager window, create a new virtual disk named VirtualDisk1 using StoragePool1
with the Simple storage layout, the Fixed provisioning type, and the maximum size.
4. From the Server Manager window, create a new 2 TB volume as drive F formatted with NTFS and a
default allocation unit.
5. From the desktop of ResDevWebVM1, open File Explorer and verify that there is a new drive F with
2 TB of available disk space.
6. Close the Remote Desktop session to ResDevWebVM1.

1. Launch Windows PowerShell as Administrator.
2. From the Windows PowerShell prompt, run:
Reset-Azure
3. When prompted (twice), sign in using the Microsoft account associated with your Azure subscription.
4. If you have multiple Azure subscriptions, select the one you want to target by the script.
Note: This script will remove Azure services in your subscription. We, therefore,
The script will take 5 to 10 minutes to reset your Microsoft Azure environment, before it is ready
for the next lab.
The script removes all storage, VMs, virtual networks, cloud services, and resource groups.
Results: After completing this exercise, you should have implemented Storage Spaces based volumes.
Question: Why would you use Storage Spaces in an IaaS virtual machine considering that
Azure already provides highly available storage built into a storage account?

Review Question
Question: Can you use an operating system disk of a virtual machine from an on-premises
Hyper-V host to deploy an Azure virtual machine?
5-1
Module 5
Implementing Azure App Service
Contents:
Module Overview 5-1
Lesson 1: Introduction to App Service 5-2
Lesson 2: Planning app deployment in App Service 5-12
Lesson 3: Implementing and maintaining web apps 5-16
Lesson 4: Configuring web apps 5-24
Lesson 5: Monitoring web apps and WebJobs 5-33

Lesson 6: Implementing mobile apps 5-38
Lesson 7: Traffic Manager 5-43
Lab: Implementing web apps 5-50

Module Overview
You can use Microsoft Azure Infrastructure as a Service (IaaS) virtual machines for a wide range of
purposes, including hosting web apps by using Internet Information Services (IIS). However, Azure also
includes a specialized Azure App Service that you can use to host web apps, mobile apps, and application
programming interface (API) apps without configuring a virtual machine and the associated platform
software. When you use App Service, you can create a web app or choose from a wide range of common
web applications, including WordPress, Drupal, Umbraco, and others. Alternatively, you can upload a
custom web application from Microsoft Visual Studio or another web developer tool. In this module, you
will learn how to implement and manage highly scalable app services.
Objectives
• Explain the different types of apps that you can create by using App Service.
• Select an App Service plan and a deployment method for apps in Azure.
• Use Visual Studio, File Transfer Protocol (FTP) clients, and Azure PowerShell to deploy web and mobile
apps to Azure.
• Configure web apps and use the Azure WebJobs feature to schedule tasks.
• Monitor the performance of web apps.
• Create and configure mobile apps.
• Use Azure Traffic Manager to distribute requests between two or more app services.
5-2 Implementing Azure App Service
Lesson 1
Introduction to App Service
There is an increasing demand for organizations to deliver great mobile and web apps that engage and
connect with their customers. Furthermore, these apps have to work on any device and should be able
to consume and integrate with data from anywhere. App Service provides a powerful platform that
integrates everything that companies need to build web and mobile apps that can work on any device.
These apps can integrate easily with other Software as a Service (SaaS) apps, such as Microsoft Office 365,
Microsoft OneDrive for Business, Facebook, and more, or connect with enterprise on-premises apps, such
as SAP, Oracle, and others.
In this lesson, you will learn about the features of App Service.
Lesson Objectives
• Describe the components of App Service.
• Describe the Web Apps feature in App Service.
• Describe the Mobile Apps feature in App Service.

• Describe the Logic Apps feature in App Service.
• Describe the API Apps feature in App Service.
• Describe the functionalities of the App Service Environment for PowerApps.

Perform this demonstration’s tasks, so that you prepare the lab environment. While the environment is
being configured, this module will describe the Azure services that you will use in the lab.
Note: The scripts that in this course uses might delete objects that you have in your
subscription. Therefore, you should complete this course by using a new Azure subscription.
You should have received sign-up details and instructions for creating an Azure learning pass,
specifically for this purpose. Alternatively, you can create a new Azure trial subscription. In both
cases, use a new Microsoft account that is not associated with any Azure subscription. This avoids
confusion in the labs and in setup scripts.
The labs in this course use custom Azure cmdlets in the Windows PowerShell command-line interface,
including Setup-Azure to prepare the Azure environment for a lab and Reset-Azure to perform clean-up
tasks at the end of a lab. Setup-Azure removes any current Azure subscription and account details from
the Azure-based Windows PowerShell session.
Before you start the lab preparation, your instructor will decide which Azure region is the closest to your
classroom location. You will need this information during the lab setup and the lab.
In this demonstration, you will learn how to:
• Sign in to your Azure subscription.
• Prepare the Azure environment.

Demonstration Steps
Prepare the Azure environment
Setup-Azure
6. When the script is complete, close Azure PowerShell.
1.
Note: This script might remove Azure services in your subscription. We recommend that you use an
Azure trial pass that was provisioned specifically for this course, and not your own Azure account.
The script will take approximately two or three minutes to configure your Azure environment and make it
ready for the lab at the end of this module.
Overview of App Service

App Service provides a comprehensive platform
for building cloud-based applications that users
can consume on any device. App Service provides
a hosted service that developers can use to build
mobile and web apps. Additionally, developers
can use this service to develop API apps and use
them for integrating SaaS apps by using logic
apps, so that they can combine business logic to
achieve different functionalities in their apps. App
Service is a new Azure service that replaced the
following Azure services: Azure Websites, Azure
Mobile Services, and Azure BizTalk Services. App
Service now is a single integrated service, and has more advanced features than its predecessors.
App Service provides the following features:
• Web Apps. Provides a common platform for developing, building, hosting, and managing web apps.
• Mobile Apps. Provides a platform for building and supporting mobile applications that users can
consume on almost any device.
• API Apps. Provides a hosted service platform that can help developers to build, host, and consume
APIs easily that are developed by using known platforms, such as ASP.NET, PHP, and Python.
• Logic Apps. Enables quick links between cloud-based apps, so that you can build connected solutions.
Overview of Web Apps

The Web Apps feature is a platform of
technologies that enable you to build web apps
in Azure without configuring and maintaining
your own virtual machines. In Azure, you can run
web apps that are developed by using the
ASP.NET, PHP, Node.js, and Python frameworks.
The Web Apps feature allows developers to use
the same set of tools and frameworks to create
web apps, provide versioning of applications,
update the apps with new functionality, and have
full monitoring functionality through the web
apps’ lifecycle.
The Web Apps feature supports common programming languages, such as C#, HTML5, PHP, Java,
Node.js, and Python, and integrates easily with familiar tools such as Visual Studio or GitHub.
The following are the key features of Web Apps:

• Gallery applications. You can use Azure Marketplace to choose from predefined solutions for popular
configurations, such as blogging sites, frameworks, ASP.NET starter apps, and others. You can find the
full selection of solutions in the Web Applications section of the Marketplace at
http://azure.microsoft.com/en-us/marketplace/web-applications/.
• Auto scaling. You can implement multiple instances of each web app to increase capacity and ensure
resilience. The Azure load balancer automatically distributes incoming requests between these
instances. You also can configure the auto-scaling functionality to handle incoming loads
dynamically.
• Continuous integration. You can deploy the web app code from cloud source-control systems, such
as Visual Studio Online and GitHub, on-premises source-control systems, such as Team Foundation
Server (TFS) and Git, and from on-premises deployment tools, such as Visual Studio, FTP clients,
WebMatrix, and MSBuild. You also can use continuous integration tools, such as Bitbucket, Hudson,
or HP TeamSite to automate build, test, and integration tests.
• Deployment slots. If you are using the Standard-tier plan for App Service, you can create two or more
slots for each web app. For example, you can create one slot for your production web app, and then
deploy your tested and accepted code there. You then can create a second slot that is your staging
environment, and deploy the new code to it to run acceptance tests. The staging slot will have a
different URL.
• Testing in production. When a new version of your staging-slot web app passes all the tests, you can
safely deploy it to the production site by swapping the slots. This also provides a simple rollback path.
If the new version causes unexpected problems, you can swap the slots once again to revert to the
old production site.
• Azure WebJobs. The WebJobs feature runs background processes for web apps, thereby offloading
most of the time-consuming and CPU-intensive tasks from the web apps. You can perform common
tasks, such as updating a database or moving log files, easily by using WebJobs.
• Hybrid connections. You can implement hybrid connections from web and mobile apps in Azure to
access on-premises resources, such as SQL databases or other published resources. By using the
Hybrid connection manager, you can share the connection across multiple web apps or mobile apps
and can limit the TCP ports required to access your network. You can also use the App Service
Environment, which is a premium feature, to integrate with an Azure virtual network. A common
scenario in which you would use hybrid connections is if your web app needs to access a database or
a web service that is running on a virtual machine that is hosted on an Azure virtual network.
Web apps often require two supporting services, data storage and file storage. The raw data that the
server-side code formats into a webpage and sends to the user often is in a database. In Azure, you can
use a SQL database to host that database. Alternatively, you can provision a database on a virtual machine
or use Azure table storage. Web apps often include media files, such as images, videos, and sound files.
Performance typically is improved if you do not store these media files on a database. In Azure, you can
use a storage account for these files. An alternative is to use a virtual machine’s file system for file storage.
Overview of Mobile Apps

The Mobile Apps feature is a part of App Service,
and it provides a platform for building and
supporting mobile applications. Mobile Apps
solves common problems for developers who
create mobile-device apps. Common
requirements of mobile apps include that they
need to:
• Store and access structured data

• Receive notifications when events happen in
the cloud
• Authenticate and authorize users based on

Facebook, Twitter, Microsoft, or other identities
• Define business logic
The Mobile Apps feature allows developers to build cross-platform apps that can run on Windows, iOS, or
Android. These apps can run solely in the cloud or connect with your on-premises infrastructure for
authentication and authorization purposes. Developers can user more than 40 SaaS API connectors for
integration with a variety of cloud apps. They can benefit from the build-push notification engine that can
send a large number of personalized push notifications to almost any mobile device that is using iOS,
Android, or Windows.
Mobile Apps has many similarities with Azure Mobile Services that Microsoft will continue to support.
However, Mobile Apps has more advantages when compared to Mobile Services, including that it
integrates with Office 365, Microsoft Dynamics CRM, Salesforce, and other important SaaS apps. It
supports Java and PHP back-end code and has built-in auto-scale and load-balancing capabilities. It also
supports multiple deployments slots for production and testing. Mobile Apps also provides alerts and log
files for monitoring and troubleshooting. Additionally, the integration of Mobile Apps with New Relic
provides deep insight into the performance and reliability of mobile apps.
You can capitalize on all of the new features by migrating existing solutions, which you developed with
Mobile Services, to Mobile Apps in one of two ways:
• Migration. This process only changes the underlying environment without any code rewrite. After you
migrate the mobile apps, you can benefit from all the new features, such as WebJobs, custom domain
names, staging slots, auto scaling, and load balancing.
• Upgrade. This process is more complex because it requires code changes. This process typically
requires you to create a second mobile app instance, update the project to use the new server
software development kits (SDKs), and then release the new mobile app.
Overview of Logic Apps

Logic apps automate a business process by
enabling quick links between cloud-based apps,
such as Office365, Google Services, Salesforce, and
many more. The Logic Apps feature allows you to
use a visual designer that you can combine with
connectors from Azure Marketplace for different
integration scenarios.
Logic apps use a workflow engine to design

business processes graphically, and then connect
them through connectors so that users can access
data and required services. The functionality of
the connectors is based on the APIs that can
trigger new instances of the workflow based on a specific event. Each step in the workflow is an action
that accesses data or services through the connector. More advanced integration scenarios can use rules,
transformations, validations, and features that are part of BizTalk Services.
When you develop your solutions, you can use either core or enterprise integration connectors. Some of
the most common core APIs include:
• Office 365 Connector. Use this API to create an action that can send and receive emails, and manage
calendars and contacts for an Office 365 account.
• Microsoft OneDrive Connector. Use this API to create an action that can connect to your personal
Microsoft OneDrive and upload, delete, or list files.
• Microsoft Yammer Connector. Use this API to connect to your Yammer subscription to post or get
new messages.
• Facebook Connector. Use this API to connect to your Facebook account and publish messages,
pictures, get comments, and perform other actions.
• HTTP Connector. Use this API to open an HTTP listener to listen an incoming HTTP request on a
particular URL.
Enterprise-integration connectors can extend app services, and provide integration and connectivity to
SAP, Oracle, DB2, Informix, and other systems.
When you develop your solution, you also can use connectors as either poll or push triggers. A common
poll-trigger scenario is to integrate your apps when new data is available at a file location, in Azure
storage, or in a SQL database. Then you can use poll trigger to get that data and use it in your app. You
typically use push triggers to start a new instance of a logic app when a specific event occurs.
Logic apps can include connectors that initiate an action. For example, you can use connectors to write,
update, or delete data from a storage account or some other linked app.
Additional Reading: For a list of supported connectors and API apps that you can use in
your logic apps, refer to: http://aka.ms/Bcinbr.
The following procedure describes how to build a logic app that sends an email from your Office 365
subscription on a recurring schedule:
1. Create the logic app:
a. Sign in to the Azure portal.
b. Click New, click Web+Mobile, and then click Logic App.
c. In the create logic app blade, fill in the following information, and then click Create:
 Name. Enter a descriptive name.
 App Service Plan. Select an existing App Service plan or create a new App Service plan.
 Pricing Tier. Choose a pricing tier for your app.
 Resource Group. Select an existing resource group or create a new resource group.
 Subscription. Select your Azure subscription.
 Location. Choose a datacenter that is closer to your location.
 Triggers and actions. Select predefined or create from scratch.
2. Create a trigger or action:
a. Select your logic app.
b. Select Recurrence API listed on the right side of the Azure portal.
c. In the Recurrence window, from the frequency drop-down list, select days, and then in the
Interval text box, type 1.
d. Select Office365 Connector from the list of APIs.

e. In the Office365 Connector Window, click Subscription, and then provide your Office 365
credentials.
f. After you sign in, in the choose an action section, click Send Email.
g. Fill the To, Subject, and Body text boxes with the appropriate email address, subject, and body
text, and then click OK.
Overview of API Apps

An API is a set of routines, protocols, and tools
that developers use for building software
applications. An API specifies how software
components should interact. APIs make building
blocks for developing apps. Developers often
need to build APIs that they can reuse in their
projects. API Apps is a hosted service platform
that can help developers to easily build, host, and
use APIs that are developed by using known
platforms, such as ASP.NET, PHP, Python, and so
on. You can create an API app by using the simple
interface in the Azure portal and then you can
integrate it with Visual Studio for developing, debugging, and managing. When you create a new API
app, Azure generates the code that enables different SaaS applications, such as Office 365 and Salesforce,
to use the API app. An API app has integrated support for Swagger API metadata that describes the API’s
capabilities and generates the client code for accessing the API by using different languages, such as, C#,
Java, and JavaScript.
Note: Swagger is popular framework for APIs that provides interactive documentations,
client SDK generations, and discoverability of the created APIs. For more information, refer to:
http://aka.ms/R09mma.
You also can benefit from enabling cross-origin resource sharing (CORS) for API apps. This allows
JavaScript to make API calls to different domains other than the original domain of the JavaScript code. A
common scenario would be a JavaScript client running in a web app, for example www.adatum.com, calls
the API that is running in an API app that has a different domain, such as customapi.azurewebsites.net.
You can build an API app that can trigger a workflow process based on certain events or conditions. For
example, you can configure the app to search for a specific string in a cloud app, such as Yammer, and
then develop a method that automatically initiates an action or response.
To create an API app, perform the following steps:
1. Create an API app:
a. Open the Azure portal, and then sign in to your subscription.
b. Click New, click Web+Mobile, and then click Api App.
c. In the Api APP blade, fill the following information, and then click Create:
 App Service Name. Provide the unique name for your API app that will be appended with
the Microsoft-owned public domain namespace .azurewebsites.net.
 Subscription. Select the subscription in which you will provision the new API app.
 Resource Group. Select an existing resource group or create a new resource group.
 App Service plan/Location. Select an existing service plan or create a new App Service plan.
2. Configure your API app:
a. In the Azure portal, select your API app.
b. In the API app blade, click All Settings.
c. In the Settings blade, in the General section, click Quick start.

d. In the Get started blade, select the desired platform. For example, you would click ASP.Net.
e. In the ASP.Net blade:

 Create a starter backend API. Select this for downloading a sample API app backend.
 Connect your client. You can either select Create a New App and download a personalized
Windows project that you can open in Visual Studio and that will be preconfigured to work
with your new hosted API, or you can select Connect an Existing App.
 Get the tools. You can download Visual Studio Community tools for developing APIs that
can run on a variety of platforms and devices.
f. In the Settings blade, scroll down to the API section, and then click API definition.
g. In the API Definition blade, you can view or change the endpoint that provides Swagger 2.0
JSON metadata.
3. Generate the client code:
a. Open your API app project in Visual Studio.
b. In Solution Explorer, right-click your API, point to ADD, and then click REST API client.
c. In the Add REST API Client dialog box, select Swagger Url, and then click Select Azure Asset.
d. In the APP Service dialog box, select your subscription, expand the resource group that contains
the API app, and then select your API app.
e. In the Add REST API Client dialog box, click OK. This will create a folder that contains yourAPI.cs
file, which contains the code that uses the generated client to call the API.
Overview of the App Service Environment

Business-critical apps often require isolated and
dedicated environments. You can use the App
Service Environment, which is a part of the
premium service plan, to enable isolated and
dedicated Azure resources for these type of apps.
You can use the App Service Environment to host
web apps, mobile apps, and API apps that require
highly scalable compute resources, isolation, and
network access.
To provide high-resource pooling, the App Service

Environment supports a front-end pool virtual
machines with P2, P3, or P4 compute resources.
Additionally, it can include up to three worker resource pools with P1, P2, P3, or P4 compute resources
that can scale differently, up to 50 instances per pool. The front-end pool commonly uses dedicated
compute resources for SSL termination and load balancing, and each worker pool runs one or more apps.
Note: P2, P3, and P4 are App Service plans that define the capabilities and capacity of
Azure fabric resources. You will learn more about App Service plans later in this module.
You create your App Service Environment in a classic virtual network within one of its subnets, and you
can use Network Security Groups (NSG) to fully isolate and secure the access to the resources. Apps that
run as a part of the App Service Environment communicate within the virtual network. You can use NSG
rules assigned to the subnet in which you provision the App Service Environment, so that you lock down
specific inbound and outbound traffic. Outbound connectivity the App Service Environment occurs
through the IP address that you configured for outbound calls. Inbound communications from the
outside of the virtual network occur through virtual IP (VIP) address of the App Service Environment.
When you create the App Service Environment, you allocate the following dedicated resources from
Azure:
• Computer resources combined in one front-end pool and up to three worker pools.
• A dedicated 500 gigabyte (GB) storage that is shared across all the apps in the App Service
Environment.
• A database that contains configuration of the environment.
• A regional virtual network v1 with a subnet.

A front-end pool contains compute resources that are commonly used for SSL termination or automatic
load balancing of app requests within an App Service Environment. The worker pools contain compute
resources that are used by the apps that are part of the App Service Environment.
To create a new mobile App Service Environment, perform the following steps:
2. On the toolbar to the left, click NEW, select Web+Mobile, and then click App Service Environment.
3. In the All Service Environment blade, in the Name box, type the unique name for your App Service
Environment. The name will be appended with the Microsoft-owned public domain
p.azurewebsites.net.
4. In the Resource Group box, select an existing resource group or create a new resource group.
5. In the Virtual Network/Location box, select an existing virtual network or create a new virtual
network. If you choose to create a new virtual network, select Location, select a virtual network
address block, create a subnet, and then select the subnet address block.
6. In the App Service Environment blade, click Scale.
7. In the Scale blade for the front-end pool, select either P2, P3, or P4 compute resource size. The
default is P2, which creates an instance with two cores, 3.5 GB RAM, and 500 GB storage.
8. In the Scale blade, you can select up to three worker pools that can contain P1, P2, P3, or P4
compute resources.
9. In the Scale blade, select the number of front-end pool instances and the number of instances for any
of the three worker pools.
10. In the Scale blade, select the number of IP addresses, and then click OK to configure scaling of the
App Service Environment.
11. Click Create to create the App Service Environment.

After you create your App Service Environment, you can open it in the Azure portal. In the Monitoring
section, you can configure different performance counters that describe the usage of CPU, Disk Queue
Length, or Average Response Time. You also can configure alerts that can trigger an email when a counter
exceeds a threshold. In the Properties blade, you can find the VIP address that is allocated for your App
Service Environment. You also can increase the number of IP addresses, such as if you need to use SSL for
a dedicated app that is part of the App Service Environment. From the Properties blade, you can access
the individual blades for each resource pool, front-end pool, and worker pool; view current resource
utilization; configure scaling of resource pools by increasing the number of instances; and configure the
auto-scaling functionality for each app service.
Question: You work as a developer for your organization, and your manager wants you to
list the major benefits of using App Service. What would you tell him?
Lesson 2
Planning app deployment in App Service
Developers have the flexibility to deploy their web solutions in several cloud-based scenarios. They can
use different scaling and configuration options based on the demands of their solutions. In this lesson,
you will learn about web apps and how they differ from Platform-as-a-Service (PaaS) cloud services and
web applications that are hosted on Azure virtual machines. You also will learn about the five plans within
which you can create web apps, and the different features that each plan supports. Finally, you will learn
how the tools and source-code control systems that developers use will influence your choice of
deployment methods.
Lesson Objectives
• Identify the differences among a web app, a PaaS cloud service, and an application that is hosted on a
virtual machine.
• Identify the differences between the five App Service plans.
• Explain the different methods to deploy and update source code in App Service.
Comparing web apps, PaaS cloud services, and virtual machines

If you want to host a web application in Azure,
you can use IaaS Azure Virtual Machines, Web
Apps, or PaaS Azure Cloud Services. The level of
control, the flexibility to scale, and the
programming languages and frameworks that you
want to use will determine which of the three
options that you select.
Note: In this course, the cloud services that

support IaaS v1 virtual machines are termed IaaS
cloud services v1. The cloud services that support
web roles and worker roles are termed PaaS cloud
services.
Note that the Resource Manager deployment model does not support cloud services.
Virtual machines
Because an IaaS virtual machine in Azure can include a web server, such as IIS or Apache, you can use it to
host web applications. This scenario is similar to running a traditional web farm to host your web
application, except that the servers are at Azure datacenters and not in an on-premises environment.
Therefore, you typically use virtual machines to migrate an on-premises web application into Azure with
as little modification as possible. You can host supporting servers, such as SQL Servers that host databases,
on other virtual machines. Load balancing is available to scale out the web application, if necessary.
If you choose to host a web application on virtual machines, this provides maximum control over your
operating system and supporting software. For example, you can install a specific version of PHP on
Apache. However, you must invest the time to update and maintain the infrastructure that you create. If
you want to scale out the application, you must provision new virtual machines to host the application’s
new instances. You can use the Remote Desktop Protocol (RDP) to connect to IaaS virtual machines.
Web apps
Alternatively, you can choose to host your web application by using the Web Apps feature. After you
create a new web app, you can upload a custom web application or choose from a wide range of popular
general-purpose web applications, including Drupal, WordPress, and Umbraco. You can build custom web
applications and host them in Web Apps by using ASP.NET, Node.js, PHP, and Python.
You can scale up web apps by changing the pricing tiers, which increases the volume of workload that a
single instance of a web app can service. Alternatively, you can scale out by installing a web app in
multiple instances, and then using Azure load balancing to distribute the traffic. However, you cannot
scale individual components of a web app separately. You also cannot gain RDP access to the web server.
You can use an Azure SQL database or SQL Server on a virtual machine to host an underlying database.
PaaS cloud services

You also can choose to build a web application as a PaaS cloud service. A PaaS cloud service consists of a
web role, which includes the application’s user interface, and worker roles, which run background tasks.
You can scale each role independently by specifying the number of role instances, which gives you
significant control over scalability. Additionally, you can connect to the servers that host your PaaS cloud
service by using RDP.
PaaS cloud services are a specialized form of web applications that are unique to Azure. An existing web
application sometimes requires a significant modification before it can run as a PaaS cloud service. You
will learn more about PaaS cloud services in Module 8.
Managing App Service plans

When you create an app in App Service, you need
to choose an existing or a new service plan. There
are five available service plans: Free, Shared, Basic,
Standard, and Premium. Multiple web, mobile,
logic, and API apps can share a single App Service
plan.
Additional Reading: For more information

on the plans and pricing, refer to App Service Plan
Pricing Details: http://aka.ms/Rgjtys.
Any App Servcie app that you create must belong to one and only one App Service plan. The App Service
plan defines the capabilities and capacity of Azure fabric resources, and is associated with a single
subscription and geographic location. The App Service plan is part of a resource group that can host
multiple plans with different capabilities. Having multiple plans as a part of a single resource group allows
you to separate the production, development, and testing environments, without impacting resources
across the plans.
Although you can associate a single plan with multiple apps, sometimes it is better to create different
service plans with different features. For example, if an app consumes more resources and has a different
scaling factor than other apps, you should host that app in a different App Service plan for better
isolation.
You can create a new service plan when you create an App Service app. When you create the service plan,
you need to provide a descriptive name and select an appropriate pricing tier and location. You can move
apps that you create in one service plan into another, should they require different capacity and scaling
options, and you can scale an App Service plan to meet the demands of apps, by changing the plan’s
pricing tier, instance size, or instance count.
The Free plan

The Free App Service plan allows you to create a maximum of 10 web, mobile, or API apps, and limits you
to 1 GB of storage. You also can create up to 10 logic apps, free of charge. The Free plan does not support
custom domain names, so you must host every app within the domain azurewebsites.net. You cannot
scale out Free tier apps to multiple instances, and they do not qualify for any service level agreement
(SLA). You can support communications and offline sync with up to 500 devices per day, and initiate 200
logic actions per day. For specific logic apps that use connectors, the Free App Service plan has a limit of
200 calls per day for core connectors and enterprise connectors. Additionally, the outbound traffic for
apps is limited to 165 megabytes (MB) per day.
The Shared plan

The Shared App Service plan has unlimited outbound data transfer and allows you to use a custom
domain, although, you cannot use secure sockets layer (SSL) to secure Shared tier web apps with custom
domains. You cannot scale a Shared tier app, and this app does not qualify for any SLAs. You can create
up to 100 web, mobile, or API apps, and up to 10 logic apps in the Shared App Service plan. Other limits
regarding storage-capacity, support for communications with devices, and calls per day from core and
enterprise connectors, are the same as with the Free 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 also qualify for the 99.9 percent uptime SLA, and you
can scale up to three instances, and use Azure load balancers to distribute the load. This plan supports
communications from unlimited mobile devices, and limits offline sync to 1,000 calls per day. It can serve
calls from 200 core and enterprise connectors.
The Standard plan

The Standard App Service plan provides up to 50 GB of storage and you can scale out apps to 10
dedicated instances. Up to five automatic scaling and staged publishing slots are available for Standard
tier apps. Apps created with the Standard App Service plan support geo-distributed deployments and
virtual private network (VPN) hybrid connectivity. They can handle 10,000 logic actions per day, and can
serve calls from 10,000 core connectors and 200 enterprise connectors.
The Premium plan

The Premium App Service plan enables maximum scale, isolation, and enterprise connectivity for the apps.
It provides up to 500 GB disk space, supports 50 instances, and can have 20 staging environments.
Comparing app-deployment methods in App Service

Developers and web-app administrators might
have different approaches for deploying web,
mobile, logic, and API apps. The chosen approach
often depends on where the source code is
located. When there is an individual developer or
a very small team, developers typically store
source code on their computers, on which they
are running an Integrated Development
Environment (IDE) that they use to write code. For
larger teams, the challenges associated with
working collaboratively often require the use of a
source control system such as Microsoft Team
Foundation Server (TFS). These source-control systems can be based in an on-premises environment or in
the cloud.
Source code on client machines

If the developers are not using a source-control system to coordinate development, they can deploy an
app to Azure directly from their chosen IDE, such as Visual Studio or Web Matrix. They also can use the
command-line MSBuild tool to script deployment processes.
Although they can use FTP to transfer files, the Web Deploy technology has extra features that make it
easier to set configuration values, such as connection strings, and reduce the deployment time.
Developers also can use the Kudu engine to push the code from any repository. Kudu supports version
control, package restore, and web hooks for continuous deployment.
Source code in an on-premises source-control system

If developers are using a source-control system that is on servers within their on-premises network, they
can configure that system to perform continuous delivery to an app service. This target app should be in
a staging slot to ensure that you can test changes before you move them to the production app.
On-premises source control systems include TFS, GitHub, and Mercurial repositories.
Source code in a cloud source-control system

If developers are using a cloud-hosted source-control system, such as Team Foundation Version Control
(TFVC) in Visual Studio Online (VSO), they can configure continuous delivery in a very similar way to on-
premises source-control systems. Developers have many choices in these systems. For example, they can
use Git for distributed source code in VSO instead of using the centralized TFVC.
Additional Reading: For more information on deployment mechanisms, refer to:

http://aka.ms/jyfupy.
Question: Given the flexibility that you have to decide where to host your apps in Azure,
what are the key factors that can influence your decision?
Lesson 3
Implementing and maintaining web apps
Teams of web designers and developers typically create web applications, using a variety of tools, such as
graphic-design packages, image-editing packages, web-design software, and IDEs, such as Visual Studio.
When the first version of a web application is complete, you must deploy it to a web server. You can
choose to use Web Apps as a web server to host your application. There are many ways to package and
deploy a web application to Azure. In this lesson, you will learn about those methods. You also will learn
how to deploy new web applications and updates as web apps by configuring IDEs, FTP tools, and source-
control software.
Lesson Objectives
• Explain how to create a new web app in Azure by using the Azure portal and Azure PowerShell.
• Explain how to use Web Deploy to deploy a web app to Azure from Visual Studio.
• Explain how to deploy updates to an existing web app.
Creating web apps

Your development team might use web servers on
their workstations or an intranet web server to
host a web application during development. If you
choose to host the web application in Azure, you
can create a new web app in Azure so that either
you or the developers can deploy the web app. If
you want to use Git or FTP to deploy the web
app’s code, you should configure the credentials
that authentication requires. You then can upload
the web app’s code and content to the new web
app so that it becomes available for browsing.
If your web app is based on the ASP.NET
framework, you can deploy it directly from Visual Studio. You can download Azure SDK for .Net that
contains a set of Visual Studio tools, command-line tools, and client libraries that simplify the process of
deploying apps to Azure.
Note: Webs apps that you deploy to the App Service are available publically. You should
not deploy a web app unless you are sure that it protects any sensitive data that it handles.
Creating new web apps in the Azure portal

To create a new web app in the Azure portal, perform the following steps:
1. On the toolbar to the left, click NEW, select the Web+Mobile link, and then click Web App.
2. In the Web App blade, in the App Service Name text box, type a unique and valid name. If the
name is unique and valid, a green smiley face appears, and Azure will append the name with the
azurewebsites.net domain name.
3. In the Subscription drop-down list, select your subscription.

4. In the Resource Group drop-down list, select an existing resource group or create a new resource
group.
5. In the App service plan/Location drop-down list, select an existing plan or create a new App Service
plan, and then select the location of the datacenter closer to you.
6. Click Create. Azure then creates the new web app.
Creating new web apps by using Azure PowerShell

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

–AppServicePlan StandardPlan
Setting up deployment credentials

If you use FTP or Git for deploying source code to Azure, then your client cannot use your Azure account
credentials to authenticate. Instead, you must set up deployment credentials. To do this in the Azure
portal, perform the following steps:
1. On the toolbar to the left, click BROWSE, and then click Web Apps.
2. In the Settings blade, scroll down to locate the Publishing section, and then click Deployment
credentials.
3. In the Set Deployment credentials blade, in the FTP/Deployment user name text box, type
ftpadminXXXX, where XXXX is a unique number.
4. In the Password text box, type Pa$$w0rd.
5. In the Confirm password text box, type Pa$$w0rd, and then click Save.
6. Close the Set deployment credentials blade.
Downloading a publishing profile

Azure can create a publishing profile for each web app that you create. This profile is an XML file with a
.publishsettings extension that you can download from the Azure portal. It includes all the credentials,
connection strings, and other settings that are required to publish a web app from an IDE such as Visual
Studio.
Create a project and a web app from Visual Studio

1. Open Microsoft Visual Studio 2015.
2. On the File menu, click New, and then click Project.

3. In the New Project dialog box, expand Installed > Templates > Visual C# > Web, and then select
ASP.NET Web Application template.
4. In the New Project dialog box, fill the following information, and then click OK:
o Name: Provide a descriptive name for the project.
o Location: Provide a location on the disk to store the new project.
o Solution: Create new solution.
o Solution Name: Provide a descriptive name for the solution.
o Add Application Insights to project: Select this check box to enable monitoring of your web
app.
5. In the New ASP.Net Project dialog box, select the MVC template.
6. On the right side of the dialog box, click Change Authentication.
7. In the Change Authentication dialog box, select No Authentication, and then click OK.
8. In the New ASP.Net Project dialog box, under the Microsoft Azure section, verify that the check
box is selected for Host in the cloud. Verify that the host option is App Service, and then click OK.
9. In the Create App Service dialog box, sign in to your Azure subscription, and then fill the following
information:
o Web App Name: Provide a unique name for your web app that will be append with the
Microsoft-owned public domain azurewebsites.net.
o Subscription: Select your subscription.
o Resource Group: Select an existing resource group or create a new resource group.
o App Service Plan: Select an existing plan or create a new service plan by choosing the name and
region.
10. Click Create to finish creation of the web app in your Azure subscription.
After you create your project, you can write the code, configure the functionality of the new web app, and
finally publish it as a new web app in Azure.
Deploying web apps

You can deploy your web apps by using several
methods, such as copying files manually by using
FTP, or synchronizing files and folders to App
Service from a cloud storage service, such as
OneDrive or Dropbox. App Service also supports
deployment by using the Web Deploy technology,
which Visual Studio, WebMatrix, and Visual Studio
Team Services all include.
Web Deploy
Web Deploy is a technology with client-side and
server-side components that synchronizes content
and configuration values with IIS servers. You can
use Web Deploy to migrate content from one IIS web server to another, or you can use it to deploy web
apps from development environments to staging and production web servers. We recommend using Web
Deploy to deploy a web app to App Service from Visual Studio.
Only IIS web servers, which host web apps, support Web Deploy. A small number of clients also support it,
including Visual Studio and WebMatrix, and it offers several advantages, including that it:
• Uploads only those files that have changed. Therefore, you can perform modifications reliably with
much less network traffic.
• Works over the secure HTTPS protocol. It does not require extra open ports on the web server’s
firewall.
• Can secure the files it transfers by setting access control lists (ACLs).
• Can use SQL scripts to deploy a database to a remote server.
• Can modify the web.config file automatically. For example, it can replace a database-connection
string so that the web app that you deploy connects to a production database.
To use Visual Studio to deploy your project as a web app in Azure, perform the following steps:
1. In Visual Studio, open your project that contains the MVC application that you plan to deploy in
Azure.
2. In Visual Studio, in Solution Explorer, right-click your project, and then select Publish.
3. In the Publish Web dialog box, follow the Publish Web Wizard.
4. On the Profile tab, in the Select a publish target section, select Microsoft Azure App Service.
5. In the App Service dialog box, sign in to your Azure subscription, select your subscription, and then
select or create a new resource group. Select an existing web app or create a new web app, and then
click OK.
6. On the Connection tab, select the publishing method to be Web Deploy, and then verify the site
name, user name, and destination URL. You can click Validate Connection to verify the existence of
the new web app and its connectivity to App Service. Click Next to proceed with the next step.
7. On the Settings tab, verify that Release is selected from the Configuration drop-down menu, and
then click Next.
8. On the Preview tab, click Publish to begin the process of copying files to the Azure server.
9. Upon a successful deployment, the default browser automatically opens the URL of your deployed
web app.
MSDeploy.exe
You implement the Web Deploy client as a command-line utility, MSDeploy.exe. Visual Studio,
WebMatrix, and PowerShell cmdlets use this utility to execute Web Deploy operations. You can use
MSDeploy.exe at the command prompt manually or as part of a batch file.
Additional Reading: To download the MSDeploy.exe tool, refer to: http://aka.ms/Fir58l.
Using Web Deploy in PowerShell

PowerShell in the resource manager model includes the New-AzureRmResourceGroupDeployment
cmdlet, which uses Web Deploy to upload either a Visual Studio package or a project file to Azure. You
can use the cmdlet to automate a web app’s deployment.
For example, you can use the following Azure PowerShell command to package and publish a web
application project from the Git repository:
New-AzureRmResourceGroupDeployment -TemplateUri
https://raw.githubusercontent.com/Azure/azure-quickstart-templates/master/201-web-app-
github-deploy/azuredeploy.json -siteName ExampleSite -hostingPlanName ExamplePlan
-siteLocation "West US" -ResourceGroupName ExampleDeployGroup
Deploying a web app by using FTP

FTP is an older protocol that is used widely for uploading web applications to web servers.
FTP clients
Azure can act as an FTP server so that you can upload your web app for publishing. However, you must
choose an FTP client, which you can use to upload your web app to Azure. There are many FTP clients
that are available, including:
• Web browsers. Many of the web browsers support FTP and HTTP. This means that you can use your
web browser to browse FTP sites and to upload content. However, advanced features, such as retries
for dropped connections, are not available in most browsers.
• Dedicated FTP clients. Several dedicated FTP clients are available for a free download. These include
FileZilla, SmartFTP, CoreFTP, and others. The advanced features of these clients make them suitable
for web-app publishing, which can involve hundreds of files with large file sizes.
• IDEs. Visual Studio and other IDEs support FTP for web-app publishing.
Configuring an FTP transfer

To publish a site by using FTP, you must configure your client with the destination URL of the remote FTP
site and the credentials that FTP can use to sign in to the FTP server. Do not use your Azure account
credentials. Rather, use the same FTP credentials that you used to configure your web app. Furthermore,
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 wide use and its broad compatibility. However, because FTP is an
older technology that is not specifically for uploading a web app’s source code, it does not have advanced
features. For example:
• FTP just transfers files. It cannot modify files or distinguish their use. Therefore, it cannot automatically
alter the database connection strings in web.config files to connect to the production database
instead of a development database. However, you can configure Web Deploy to make this
modification.
• FTP always transfers all files that you select, regardless of whether they have been modified. This can
cause an operation to upload many files unnecessarily, since they remain unchanged from their
previous upload.
Updating web apps

After you deploy a web app to Azure, you rarely
cease developing it. In most cases, developers add
new features and fix bugs to improve the app and
ensure a compelling user experience. You can
deploy these changes in different ways,
depending on the location of your source code
and the deployment tool that you choose.
If you use FTP for deployment, you simply upload

new files and overwrite any changed files. Note
that FTP cannot distinguish changed files
automatically, so you must keep a careful record
of altered files or overwrite all the files in the site.
If you take the second approach, even a small update requires a lengthy upload operation However, if
you use Web Deploy, MSDeploy.exe compares the files in the source and destination, and then uploads
only the modified files.
Continuous deployment
Continuous delivery is a recent approach to software development in which a project’s source code
changes regularly due to bug fixes, and new and improved features. Continuous deployment is a part of
the continuous delivery model. It involves regular and automatic builds and deployments of a project to a
staging environment. If you develop a web app by using a centralized source-control system, such as TFS
or GitHub, you can configure continuous deployment of that web app to Azure, on an automated
schedule or in response to any committed changes.
To enable and use continuous deployment, you must:
1. Connect the project to a web app. In the Azure portal, you must configure the location of your
source-code repository and provide credentials that 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 deploy an operation.
The precise steps involved in this configuration depend on the repository that you are using.
Additional Reading: For more information on the configuration steps for a Git repository
in Visual Studio Online, refer to Continuous delivery to Azure using Visual Studio Online and Git:
http://aka.ms/T39yxb.
Staging and production slots

Before you deploy the source code to a public-facing web app, you must ensure and test its integrity and
reliability. Therefore, it is important to implement a strict testing and acceptance regime that identifies
bugs and other issues in the code before you deploy it to the production web app. You can perform much
of this testing in the development environment. For example, you can run unit tests on developers’
computers. However, the final testing location should be the staging environment. The staging
environment should match the production environment as closely as possible.
If you are using the Standard tier web apps, you can create two or more slots for each app. You can create
one slot for the production web app and deploy the tested and accepted code there. You can create a
second slot as the staging environment. You can deploy the new code to this staging slot, and then use it
to run acceptance tests. The staging slot has a different URL for browsing.
When the new version in the staging slot passes all the tests, you can deploy it to production safely by
swapping the slots. This also provides a simple rollback path. If the new version causes unexpected
problems, you can swap the slots one more time to move back to the old production site.
Best Practice: If you are using continuous deployment, you should never configure it to deploy
the code to a production web app. This would result in untested code in a user-facing
environment. Instead, you can configure deployment to a staging slot or a separate web app,
where you can run certain 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:
• Connection strings
• Handler mappings
• Monitoring and diagnostic settings
For staging, you typically run the web app against a dedicated staging database, which you define in the
connection string. When you swap slots, the new production database will use the database that you were
using while staging the app. If you want to continue to use the original database because it contains up-
to-date production data, you must edit the connection string in the new production slot. You should do
this only if the database schema has not changed in the new version. If the schema has changed, you
must migrate the production data into the staging database before you swap.
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
Staging slots are available publically, but because the URL is not widely known, Internet users are unlikely
to find your staging site. However, you might wish to restrict access to your staging slot so that only your
developers and the testing team can access it. You can do this by adding the IP address white lists to the
web.config file in the web app.
Demonstration: Deploying web apps by using Web Deploy

• Create a new web app in the Azure portal.
• Browse the new web app in the Azure portal.
• Obtain a publishing profile.
• Deploy line-of-business (LOB) application in Web Apps.

Demonstration Steps
Create a new web app in the Azure portal
1. Start Internet Explorer, browse to http://portal.azure.com, and then sign in by using the Microsoft
account that is either the Service Admin or co-admin of your subscription.
2. From the Azure portal, create a new web app in a new resource group named AdatumRG.
3. Create a new App Service plan named WebAppStandardPlan, located in the Azure region near your
location, and choose S1 Standard as the pricing tier.
Open the new web app from the Azure portal

1. After the web app’s creation is complete, use the URL in the Essentials section of the web app blade
in the Azure portal to browse to its default webpage.
2. Close the Internet Explorer tab showing the default webpage.
Obtain the publishing profile

1. From the Azure portal, download the publish settings profile.
2. Save the profile in the Downloads folder on the local computer.
Deploy an LOB application in Web Apps

1. Open Visual Studio 2015 and then open D:\DemoFiles\Mod05\AdatumWebsite
\AdatumWebsite.sln.
2. From the Solution Explorer, publish the AdatumWebsite project. Use the publish settings profile file
from the Downloads folder.
3. Verify that the Adatum web app is open in the Microsoft Edge browser, and then verify the current
address of the web app.
4. Close the Home Page tab in the browser.

Question: What are the benefits of deployments slots and how can you move your web app
between different slots?
Lesson 4
Configuring web apps
After you create and deploy a web app, you have many settings that you can configure on an ongoing
basis. For example, you can configure SSL and web-app certificates to support encryption; link databases
and storage accounts to the web app, which eases scalability and monitoring; and scale the web app to
handle peak demand. In this lesson, you will learn how to configure a web app for optimal performance
and cost efficiency, and how to use WebJobs to schedule scripted tasks that maintain your web app.
Lesson Objectives
• Explain how to configure a web app’s application and authentication settings.
• Explain how to configure virtual networks and hybrid connectivity for web apps.
• Explain how to scale web apps and configure availability.

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

After you create your web app in the Azure portal,
you can access the Application settings blade
from the All Settings link to configure the
settings for the web app. You can configure the
following settings in the Application settings
blade:
• Framework versions. Use this setting to
select from all the supported versions of
development frameworks. Server-side code
that executes to render webpages requires a
framework, which developers select when
developing a web app. Azure supports the
ASP.NET, PHP, Java, and Python frameworks. Older web apps might require an older version.
• Platform. Use this setting to control whether to run the server code in 32-bit or 64-bit mode. The
64-bit mode is available only for Basic, Standard, and Premium tier web apps.
• Web Sockets. Use this setting to enable web sockets, which allow for two-way communication
between a server and a client. Developers can build chat rooms, games, and support tools by using
web sockets.
Note: Many developers in ASP.NET use the SignalR package to build two-way messaging
into their web applications. SignalR is built on web sockets.
• Always On. Use this setting to enable regular pinging of a web app with a simple request, which
ensures that the app’s code remains in memory and does not need to be recompiled and reloaded.
Many web-development technologies, such as ASP.NET and PHP, unload a web app from memory
when there are no requests for a prolonged period. After this period, if the web app receives a new
request, the code might need to compile and reload before it can send a response to the user. This
process can affect response time. The Always On feature is available only for web apps in the
Standard and Premium tiers.
• Managed Pipeline Version. Use this setting in integrated or classic mode to manage versioning. An
application pool that is running in the integrated mode benefits from the integrated request-
processing architecture of IIS and ASP.NET, so this is default mode for new web apps. Legacy apps
that run in the classic mode, which is equivalent to the IIS 6.0 worker-process isolation mode, use
separate process for IIS and ASP.NET, with duplicate processes for authentication and authorization.
• Auto Swap. Use this setting to enable automatic swap between the production and staging
environments each time you upload new updates to the staging slot.
• Debugging. Use this setting to enable remote debugging and select the version of Visual Studio to
connect directly to the web app.
• App Settings. Use this setting to pass custom name/value pairs to your application at runtime. Work
with your development team to determine what settings the web app’s code requires. For example,
you can use an app setting to specify an administrator’s email address. The web app’s code could use
this setting and display it in an appropriate place on the site.
• Connection Strings. Use this setting to enable the web app to connect to a database. Most web apps
use databases to store all dynamic data, and they cannot function without a connection to one or
more databases. Configuration files, such as the web.config file, store connection strings. You can use
the Connection Strings setting to override these connection strings without modifying and uploading
a new web.config file.
• Default Documents. Use this setting to specify the pages that display when users open your web
app. Work with your developers to ensure that the web app’s home page appears in the default
documents list. Optimize the web app by ensuring that the home page is at the top of the list.
• Handler mappings. Use this setting to add custom script processors for configuring specific
extensions, such as .php or .asp. To add a custom script processor, provide the path of the script
processor and any additional arguments that you can use with the script.
• Virtual applications and directories. Use this setting to add additional virtual applications and
directories to your web app by specifying physical paths.
Diagnostic logs
You can access the monitoring settings for a web app by clicking the All Settings link, and then clicking
the Diagnostic logs link. In the Logs blade, you can configure application logging either by using the file
system for streaming log feature or a blob to collect the logs from the configured storage account. You
also can configure the logging level (Error, Warning, Information, or Verbose) and how failed requests are
handled for diagnostic purposes.
Custom domain names

If you have registered a custom domain name, such as adatumcorp.com, with a domain registrar, you can
use that domain name to host your site. All Azure sites without custom domain names are in the
azurewebsites.net domain. You can set a custom domain for web apps that you create in the Shared,
Basic, Standard, and Premium tiers. You can configure your custom domain by verifying the domain’s
ownership by clicking the All Settings link, clicking Custom domains and SSL link, and then on the
command bar, clicking Bring your external domain. You can verify your domain by creating a CNAME
resource record in your Domain Name System (DNS) server that points from your custom domain, such as
www.adatumcorp.com to webapp.azurewebsites.com. You also can create an A resource record that can
map your custom domain name with the public IP address that Azure allocates for your web app.
Optionally, you can verify your custom domain with CNAME resource record, which maps
awverify.yourdomain to awverify.yourwebapp.azurewebsites.net.
Certificates
If you want to use SSL to encrypt communications between the web browser and the server that is hosting
the web app, you must obtain and upload a certificate from a recognized certificate authority. Use the
Certificates section in the Custom Domain and SSL blade in the Azure portal to add a certificate to your
site. To use SSL with a custom domain, you must ensure the custom domain appears in the certificate
when you purchase it from the certificate authority. After you upload the certificate, you can bind it to the
custom domain by using the SSL Bindings table. The following is the process for enabling HTTPS for a
custom domain:
1. Create your SSL certificate that contains your custom domain that you define in the Subject Name or
Subject Alternative Name property of the certificate. You also can use a wildcard certificate for this
purpose.
2. Configure the Standard or Premium pricing tier, because only these tiers allow the usage of HTTPS for
a custom domain.
3. Configure SSL in your app by uploading your certificate and configuring with your custom domain
name for the web app.
4. Enforce HTTPS on your app (optionally) by configuring the URL Rewrite module that is part of App
Service. URL Rewrite defines rules in the web.config file of the web app to force incoming requests for
the web app to use an HTTPS connection.
Note: For more information on how to enable HTTPS for an app in App Service, refer to
Enforce HTTP on your app: http://aka.ms/X0xh9y.
Configuring authentication and authorization in App Service

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

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

Web apps and mobile apps often require a
connection to a database or a web service that
might run as PaaS or that you implement as a
service on an Azure virtual machine. In case the
database or the web service runs on a virtual
machine, App Service might require integration
with the virtual network in which the virtual
machine is running. With virtual network
integration, apps communicate with virtual
machines that contain databases and web services
by using private IP addresses that are not exposed
to the Internet. To integrate app services with a
virtual network, you need to create a Standard or
Premium service plan and use classic virtual networks. You can enable virtual network integration for
multiple apps, but all of them should run a supported service plan and all must belong to the same
subscription. You must configure each virtual network with point-to-site VPN and dynamic routing
gateway. Web apps use point-to-site VPN connection to connect with the virtual network. If that virtual
network also connects to your on-premises network with a site-to-site VPN, the apps also can access on-
premises resources, such as a database server that is running in your datacenter.
To enable virtual network integration for your app, perform the following steps:
1. Sign in to the Azure portal, and then select your web app for which you want to configure virtual
network integration.
2. In the Settings blade, in the Routing section, click the Networking link.
3. In the Network Feature Status blade, under the VNet Integration section, click the Setup link.
4. In the Virtual Network blade, select an existing virtual network or create a new virtual network.
5. In the Create a Virtual Network blade, type a descriptive name for the virtual network, choose an
address space, and then optionally configure a primary and secondary DNS server.
6. Click OK to confirm the creation of the virtual network.
If you need to enable App Service apps to connect with on-premises resources, you can use hybrid
connections. You can implement hybrid connections from web apps and mobile apps in Azure to access
on-premises resources behind your firewall, such as SQL databases or other published resources. A hybrid
connection provides secure connectivity with on-premises resources that are configured with static TCP
ports. You can limit the connection to only specific on-premises resources, and you can share a hybrid
connection across multiple apps. Developers use the same connection string from web apps and mobile
apps to connect to on-premises resources by using the configuration of hybrid connections. You establish
security in a hybrid connection between apps and on-premises resources by using Shared Access
Signature (SAS) authorization. The configuration of the on-premises resources is set such that it does not
require you to reconfigure the firewall or any special hardware. It only requires outbound connectivity to
the specific TCP port or HTTP connectivity from your on-premises network. However, only some TCP ports
are used by hybrid connections:
Port Purpose
9350-9354 Port 9530 probes to determine whether TCP connectivity is

available. Outbound connections use these ports.
5671 Acts as a control channel with on-premises resources.
80 and 443 Act as fallback ports for data transmission and to control
connectivity with on-premises resources.
After you enable a hybrid connection between web apps and on-premises resources, you need to install
the Hybrid Connection Manager in your infrastructure. Hybrid Connection Manager is an agent that you
must connect to on-premises resources and Azure.
To create a hybrid connection with your apps, perform the following steps:
1. Sign in to the Azure portal, and then select your web app for which you want to configure hybrid
integration.
2. In the Settings blade, in the Routing section, click the Networking link.
3. In the Network Feature Status blade, under the Hybrid Connections section, click the Configure
your hybrid connection endpoint link.
4. In the Hybrid connections blade, click Add.
5. In the Create hybrid connection blade, in the Name text box, type a descriptive name.
6. In the Create hybrid connection blade, in the Hostname text box, type the fully qualified domain
name (FQDN) of the on-premises resource.
7. In the Create hybrid connection blade, in the Port text box, enter the static port for the on-premises
resource for which you want to establish connection.
8. In the Create hybrid connection blade, click the BizTalk Service link.
9. In the Create BizTalk Service blade, in the Name text box, type a unique name that will be
appended with the Microsoft-owned public DNS domain, biztalk.windows.net.
10. In the Resource Group section, select an existing resource group or create a new resource group.
11. In the Location section, choose the Azure region closer to your location.
12. Click OK to confirm the creation of the hybrid connection.
13. After the hybrid connection is created, click it to configure connectivity.
14. In the Hybrid connection blade, click the Listener Setup icon.
15. In the Hybrid connection properties blade, in the On-Premises Hybrid Connection Manager
section, click the Install and configure now link.
16. Follow the setup to install Hybrid Connection Manager on the resource that you want to connect.
Configuring availability and scalability

The scaling options that are available for your web
app depend on the service tier you select for the
app. For the Shared and Basic tiers, you can only
increase the size of an individual web app instance
or the number of instances. For the Standard and
Premium tiers, you can also configure automatic
scaling. You can scale a web app based on a
schedule, which can be helpful when you expect a
peak load. Alternatively, you can configure the
app to scale automatically by setting a metric that
will trigger scaling when it reaches a value that
you preconfigure.
Additional Reading: For more information on scaling web apps, refer to:
http://aka.ms/Vaut94.
To configure scaling for a web app, perform the following steps:
1. In the Azure portal, click the web app that you want to configure.
2. In the web app blade, click the All Settings link, and then click the Scale Up (App Service Plan)
link.
3. In the Choose your pricing tier box, select Share or Basic to configure simple static scaling. If you
want to use automatic scaling, select Standard or Premium.
4. In the Settings blade, click the Scale Out (App Service Plan) link.
5. In the Scale setting blade, you can scale up by selecting a larger Instance Count.
6. For the Standard and Premium tier web apps, you can configure automatic scaling based on a specific
CPU utilization percentage. You can create automatic configuration of new instances to cover an
expected spike in the demand, on the basis of CPU percentage.
7. For the Standard and Premium tier web apps, you can configure automatic scaling based on a
schedule and a performance rule. Click Add Profile, define the name of the profile, and then
configure the profile to use different instances based on a fixed date. Select a recurrence schedule for
different times of the week or configure the profile with a fixed instance count.
Best Practice: When you specify a schedule for scaling instances, consider that it can take several
minutes for each instance to start and become available to users. Therefore, ensure that you have
enough time between the start of the schedule and the point when you expect peak traffic to
start.
Implementing WebJobs
WebJobs is a feature of App Service that enables
administrators and developers to run automated
background tasks:
• On demand. Tasks runs whenever an
administrator executes them.
• Continuously. Tasks continuously reexecute

their main methods. For example, a task
might continuously check for the presence of
new files to process.
• On a schedule. Tasks run at times that the site
administrator specifies.
You use WebJobs for important maintenance tasks that do not affect content delivery to users, such
as for:
• Image processing. Processes that must be run on uploaded images are often CPU intensive.
• File maintenance. For example, you might want to scan log files and remove unimportant events.
• RSS aggregation. Importing information from an RSS feed can be CPU-intensive when there are many
articles.
Best Practice: By default, web apps unload and halt after a prolonged period of inactivity. This
also interrupts any WebJobs in process. To avoid these halts and prevent interruption of
WebJobs, use the Always On feature.
The operations and logic that a WebJob performs are defined in a script file. This file can be a:
• Batch file
• PowerShell script
• Bash shell script
• PHP script
• Python script
• Node.js script
The type of script that you create for a WebJob depends on your own experience. For example, if you are
a Windows administrator with little web development experience, you are more likely to code WebJob
operations as a Azure PowerShell script than as a Node.js script. Use the following procedures to create
and monitor WebJobs.
Creating a WebJob
To create a WebJob, first compress your script file and any supporting files that it requires into a zip file,
and then perform the following steps:
1. In the Azure portal, click the web app that you want to configure with a WebJob.
2. In the Settings blade, click the Webjobs link.
3. In the WebJobs blade, click Add.
4. In the NAME text box, type a descriptive name for the new WebJob.
5. In the HOW TO RUN drop-down list, select On demand or Run continuously.
6. In the File Upload text box, browse to the zip file that you created.
7. Click Create to finish creation of the WebJob.
At the time of the writing this course, the Azure portal did not support the creation of scheduled
WebJobs. However, you could create scheduled WebJobes in the Azure classic portal. To create a
scheduled WebJob in the Azure classic portal, perform the following steps:
1. In the Azure classic portal, in the navigation pane on the left, click WEB APPS.
2. Click the relevant web app, and then click the WEBJOBS tab.
3. On the command bar at the bottom, click Add.
4. In the NAME text box, type a descriptive name for the new WebJob.
5. In the CONTENT text box, browse to the zip file you created.
6. In the HOW TO RUN drop-down list, select Run on a Schedule.
7. If you are creating a scheduled WebJob, in the SCHEDULER REGION drop-down list, select an Azure
datacenter where you want the scheduler to run.
8. Specify either a one-off time for the job to execute or a recurring schedule.
Viewing the WebJob history

The WebJob history shows when the WebJob was run and the result of the script execution. To access the
history, perform the following steps:
1. In the Azure portal, click the web app that runs the WebJob, and then click the WebJob link.
2. For the relevant WebJob, click the link in the Logs column. Azure displays the WebJob details page.
This page displays the script that is run, the duration of the script execution, and the status.
3. To see further details, click the link in the TIMING section, and then click Toggle output. Individual
events in the execution of the WebJob are displayed.
4. To see the output in a separate browser window, click the download link.
Demonstration: Configuring web-app settings and auto-scaling, and

creating a WebJob
• Configure web-app settings.
• Configure auto-scaling.
• Create a WebJob.
Demonstration Steps
Configuring web-app settings

1. In the Azure portal, navigate to the web app that you created in the previous demonstration.
2. In the Settings blade, under the General section, click the Application settings link.
3. In the Application settings blade, under General settings, review the current settings:
o .Net Framework version

o PHP version
o Java version
o Python version
o Platform
o Web Sockets
o Always On
o Managed Pipeline Version.
o Auto Swap
o Debugging
4. In the Settings blade, scroll down to the App Service plan section, and then click Scale Up (App
Service Plan).
5. In the Choose your pricing tier blade, review the different App Service plan tiers, and then close the
blade.
Configure auto-scaling options

1. In the Settings blade, click Scale Out (App Service Plan), and then in the Scale by drop-down
menu, review the scaling options:
o An instance count that I enter manually
o CPU Percentage
o Schedule and performance rule
2. In the Scale by drop-down list, select schedule and performance rules. Configure the scale out by
2 instances if the CPU utilization percentage is greater than 80. Configure the cool-down time to be
5 minutes.
Create a WebJob
1. In the Settings blade, scroll down to the Web Jobs section, and then create a WebJob named
AdatumWebJob.
2. Configure the WebJob to run continuously as a single instance. Upload the following file:
d:\demofiles\Mod05\AdatumWebJob.zip.
3. In the WebJobs blade, click the logs URL for AdatumWebJob, and then verify that the WebJob has
run and returned the current open processes.
Question: How can you configure WebJobs tasks to run?

Lesson 5
Monitoring web apps and WebJobs
Running web apps consume resources and incur costs, and also can generate errors. For example, users
might request webpages that do not exist, and an error might display. Azure allows you to have full
control of your web app’s behavior by providing several diagnostic logs and tools. In this lesson, you will
see how to configure logging for your web app, and how to view and analyze the logging data.
Lesson Objectives
• Identify the different ways to monitor web apps.
• Explain how to configure site diagnostics and application diagnostics to log a web app’s behavior.
• Explain how to use the Kudu user interface to access further information about your web app.
Monitoring web apps

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

You can access the application and site diagnostic
logs by using FTP. You can provide an FTP link in
the Quick Glance section of each web app’s
DASHBOARD tab. You can use this link in your
web browser or paste it in a dedicated FTP client,
such as CoreFTP. To access the logs, you must
authenticate with deployment credentials that you configure for the FTP server and Git.
The logs are in the following folders:

• Application logs: /LogFiles/Application
• Detailed error logs: /LogFiles/DetailedErrors
• Failed request traces: /LogFiles/W3SVC#########/
• Web Server logs: /LogFiles/http/RawLogs
• Deployment logs: /LogFiles/Git
To examine the failed request traces, ensure you download both XML and XSL files to the same folder.
You can then open the XML files in Internet Explorer.
Instead of using FTP, you also can download the logs by using the Save-AzureWebsiteLog Windows
PowerShell cmdlet, as follows:
Save-AzureWebsiteLog -Name MyWebapp -Output .\LogFiles.zip

You also can use the Azure cross-platform command-line interface (X-Plat-CLI) to download logs:
Azure site log download MyWebappname
If you want better filtering and search capabilities, you can view the application logs in Visual Studio,
which provides the Application Insight tool. To use this tool, install the Application Insight SDK and then
add it to your project in Visual Studio. Then add Trace Listener to your project by selecting Manage
NuGet Packages, and then selecting Microsoft.ApplicationInsights.TraceListener. Finally, upload the
project to Azure, and then monitor the log data, together with requests, usage, and other statistical
information.
For real-time logging information that can be useful during development, developers can stream the logs
into the development environment. To do this, they can run the following PowerShell command:
Get-AzureWebSiteLog -Name webappname -Tail
You can store diagnostic logs in a file system, a table storage, or a blob storage. File system logs provide
basic information such as time, process ID, event level, and a message that explains the event. Table
storage logs contains additional properties, such as instance ID, thread ID, row key, and so on. Blob
storage logs are stored as comma-separated values and provide similar functionality as table storage logs.
Diagnostic logs are easy to understand but can be challenging to analyze when they contain a large
quantity of data. One way to analyze diagnostic logs is to use Microsoft Azure HDInsight.
Additional Reading: For more information, refer to Analyze Windows Azure Web app
application logs using transient HDInsight cluster: http://aka.ms/Wrwug2.
Monitoring web apps in the Azure portal

The Azure portal also includes a Monitoring section for every web app. You can use this to view
performance counters that describe how your web app uses resources such as CPU time and network
traffic. Some of the most interesting counters include:
• CPU Time
• Data In
• Data Out
• HTTP Server Errors
• Requests
• Monitoring working set
Other metrics that you can add to the graph include:
• Average Memory Working Set
• Average Response Time
• Various HTTP error type counts
• HTTP Successes
By adding these counters and displaying them in the graph, you can examine how the demand and the
web app response have varied over an hour, 24 hours, or seven days.
You also can set alerts that can trigger an email when a counter exceeds a threshold. Typically, you would
use alerts to notify your team of administrators automatically when there is a demand spike or other
performance issues. To add an alert, perform the following steps:
1. In the Azure portal, click the web app you want to monitor.
2. From the Monitoring section, click the Requests and errors graph.
3. On the Metric tab, click Add alert.
4. In the Add an alert rule blade, in the NAME text box, type a descriptive name.
5. In the Metric drop-down list, select the metric to which you would like to add an alert.
6. In the CONDITION drop-down list, select a condition, such as greater than.
7. In the THRESHOLD text box, type the value that should trigger the alert.
8. In the Period drop-down list, select the period during which the value should exceed the threshold.
9. Select Send an email to the service administrator and co-administrators.
10. Optionally in the Webhook text box, type the HTTP/HTTPS endpoint to route Azure alerts to other
notification channels.
11. Click OK to finish the creation of the alert.
Configuring application and site diagnostics

If you want to troubleshoot a web app’s errors or
improve its performance, you need to gather
information about the behavior of the web app.
The Web App feature includes application
diagnostics and site diagnostics, which you can
configure to record such information for later
analysis.
Best Practice: Configure site diagnostics and

application diagnostics to record detailed
information only when you are investigating a
web app’s behavior. When you complete your
investigation and want to tune your web app for high performance, you should minimize the
amount of information the diagnostic tools log, because logging has a small but potentially
significant impact on a web app’s performance.
Application diagnostics
Application diagnostics allows you and web app developers to capture and log individual events
that occur as the web app code executes. To record such an event, the developer must use the
System.Diagnostics.Trace class to send a message. Developers often send trace messages in error
handling code but they can also send them simply to record a successful operation.
Application diagnostics are turned off by default, which means that trace messages are not recorded. If
you switch on application diagnostics, you must configure the following settings by clicking the
Diagnostic logs link in the Settings blade for the web app:
• Log storage location. Choose whether to store the application diagnostic log in the web app file
system, a table in an Azure storage account, or a blob container in an Azure storage account. You can
choose to enable any combination of these locations.
• Logging level. Choose whether to record informational, warning, or error messages in the log. The
verbose logging level records all the message the application sends. You can configure a different
logging level for each log storage location.
• Retention period. Logs stored in a blob storage are not deleted automatically. If you want to enable
automatic deletion, you must set a retention period.
Site diagnostics
You can use site diagnostics to record information about HTTP requests and responses, which are the
communications between the web server and the web browser. The following are the site diagnostic
settings that you can enable or disable:
• Detailed Error Logging. In HTTP, any response with a status code of 400 or greater indicates an
error. Often, users might only see a simple error page with no technical details. The details stored in
site diagnostic logs might help you to diagnose the problem. If you enable the Detailed Error
Logging option, users can see the detailed information about an error.
• Failed Request Tracing. This option enables you to log rich-tracing information when an error
occurs. Because the trace includes a list of all the IIS components that processed the request and the
timing information, you can use this trace to isolate problematic components.
• Web Server Logging. This option enables the standard W3C extended log for your web app. Such a
log shows all requests and responses, client IP addresses, and timings and you can use it to assess
server load, identify malicious attacks, and study client behavior.
Additional Reading: For more information on diagnostic logging, refer to Enable

diagnostic logging for Azure Websites: http://aka.ms/A42xut.
Using Kudu
Project Kudu is an open-source component of
Web Apps that implements Azure’s support for
continuous deployment from Git and Mercurial
source-code control systems. It also includes the
code that supports WebJobs.
Kudu includes a user interface that publishes

diagnostic information and can help you obtain
troubleshooting and performance information.
Accessing the Kudu user interface

Every web app includes a hidden Kudu site. To
access this, add the “scm” sub-domain to the
azurewebsites.net fully-qualified domain name for your site. For example, if your web app is found at:
http://mywebapp.azurewebsites.net
You can access the corresponding Kudu user interface at:
https://mywebapp.scm.azurewebsites.net
To access the information in Kudu, you must authenticate with your Azure administrator account and
encrypt the connection by using SSL. The default page displays information about the IIS environment
that is hosting the web app. You also can run commands, either at a Windows command prompt or in
Windows PowerShell, by using the links on the Debug Console menu in the Kudu user interface.
The Process Explorer tab shows a list of all the processes within the web app and includes information
such as their memory usage and uptime. For each process, you can find out what DLLs it has loaded, the
threads it runs, and the environment variables that are in place.
Other links in Kudu enable you to view diagnostic log files and add NuGet extensions to the web app.
Demonstration: Using Kudu to monitor a WebJob

In this demonstration, you will learn how to use Kudu to monitor the status of a WebJob.
Demonstration Steps
1. In Internet Explorer, in the address bar, modify the URL of your web app to match the following
format:
https://yourWebApp.scm.azurewebsites.net
This opens the Kudu interface.
2. Under the Rest API section, locate the WebJobs entry, and then click the continuous link.
3. In the dialog box, click Save. Internet Explorer saves the log file to the Downloads folder.
4. Open the log file by using Visual Studio.
Question: How can you access the Kudu interface for a web app that is created in Azure?
Lesson 6
Implementing mobile apps
You can use many services and tools that are available in Azure as a backend for mobile apps that run on
phones, tablets, and other devices. Microsoft enables this by adding the Mobile Apps feature to App
Service. Mobile Apps provides the features that are widely used by mobile app developers in a single
service with a single API. In this lesson, you will learn how to create and administer a mobile app backend
in Azure to support a mobile app created by your team of developers.
Lesson Objectives
• Explain how to create and configure a new mobile app by using the Azure portal.
• Explain how to configure external authentication providers in a mobile app.
• Describe how to deploy a mobile app by using a publishing profile or by using continuous
deployment.
• Describe how to implement a mobile app by using the Azure portal.
Creating and configuring Mobile Apps

The Mobile Apps feature provides a complete
platform for developing mobile apps that users
can use on almost any device. You can use familiar
tools and SDKs to develop your mobile apps, and
then deploy them by using the same deployment
methods that you used for web apps. The
following are the most important features of
Mobile Apps:
• Single sign-on. You can enable authentication

for your mobile app to use Azure AD, or other
cloud providers, such as Facebook, Google,
Twitter, and Microsoft account.
• Offline synchronization. You can build apps that can work offline and then synchronize the data when
the device becomes online.
• Push notifications. You can benefit from the push notification engine that delivers large number of
notifications to devices for events that happened in the cloud.
• Auto scaling. You can configure auto-scaling of instances based on the utilization for mobile apps
that are created in the Standard or Premium servicing tier.
• WebJobs. You can use WebJobs for background processes.
• Connect to a SaaS API. You can integrate your mobile app with cloud applications, such as Office 365,
Salesforce, Dropbox, and more.
• Virtual network integration. You can connect mobile apps with background services, such as
databases that can run on a virtual machine that is a part of Azure virtual network. You can also
connect the mobile apps with on-premises servers.
• Staging environment. You can create multiple staging environments to test your mobile app before
you move it to the production environment.
To create a new mobile app, perform the following steps:
2. On the toolbar to the left, click NEW, select the Web+Mobile link, and then click Mobile App.
3. In the Mobile App blade, in the App Service Name text box, type a unique valid URL for the mobile
app. The mobile app must be unique within the azurewebsites.net domain.
4. In the Resource Group drop-down list, select an existing resource group or create a new resource
group.
5. In the App Service plan/location drop-down list, select an existing plan or create a new App Service
plan.
6. Click Create to finish the creation of the mobile app.
7. After the backend for the mobile app is created in the Settings blade, click the Quick start link.
8. In the Quick start blade, choose the language for the business logic code. Work with your developer
team to choose the language that you want.
9. If you have chosen Windows, click the Connect a database section.
10. In the Data connections blade, click Add.

11. In the Add data connection blade, select SQL Database, and then click the Configure required
settings link.
12. In the Database blade, type a descriptive name, select Pricing ties, and then click Configure
required settings to configure the required settings for the server.
13. In the New Server blade, in the Server name text box, type the unique name for the server. The
server name will be appended with the Microsoft-owned public domain name
database.windows.net.
14. In the Server admin login text box, type the administrator account, in the Password and Confirm
Password text boxes, type the administrator password.
15. Select Allow azure services to access server, and then click OK to confirm the creation of the server.
16. In the New database blade, click OK.
17. In the Add data connection blade, click OK.
18. In the Windows (C#) blade, under the Create a table API section, select the backend language as
C# or Node.js.
19. Click the Download link, and save the compressed files on your computer. These files contain the
startup project that you can open in Visual Studio, develop the code, and then publish it to Azure.
After you create the backend for the mobile app, the next logical step is to develop and publish its code
in Azure. You can develop your mobile app for iOS, Windows, or Android by using the similar
development environment that you used for web apps. Microsoft provides SDKs for these platforms that
you can integrate with Visual Studio.
You can download sample code for developing your mobile apps based on the platform. The sample code
is preconfigured to work with your mobile app.
Configuring authentication
Azure and social-networking sites are very
popular, and a majority of your app’s potential
users typically have Azure AD, Microsoft,
Facebook, Twitter, or Google user accounts
already. They also trust these services because
they use them on a regular basis. When you
enable users to authenticate in your mobile app
with the credentials from these external services,
you make it easier for them, as they do not have
to create a new account for your app and
remember new credentials.
To configure your mobile app to use Azure AD as

an identity provider, perform the following steps:
1. In the Azure portal, click the mobile app that you want to configure.
2. In the web app blade, click the All Settings link, and then in the Settings blade, click the
Authentication/Authorization link.
3. In the Authentication/Authorization blade, under the App Service Authentication section, click
On to configure authentication and authorization for your mobile app.
4. In the Authentication Provider section, click Azure Active Directory.
5. In the Azure Active Directory Settings blade, under the Management mode section, click Express.
This will create a new registration for the mobile app. You also can use existing Active Directory App
registration.
6. Click OK to confirm Azure AD registration.
7. In the Authentication/Authorization blade, click Save to register the authentication provider.
Note: You can also provide configuration settings manually by creating a registration in
Azure AD, and then use that information in App Service. This procedure is explained in Module 9
“Implementing Azure AD” in the topic “Integrating applications with Azure AD.”
For mobile apps that require greater security, you can prevent invoking APIs anonymously. Based on the
platform that you choose to develop your mobile app, you can configure this differently:
• Node.js. Add the following line to the Node.js server script:
table.access =”authenticated”
• .NET (C#). Add the Authorize attribute to the controller class.
The next step is to configure the app to authenticate users before requesting resources from the mobile
app.
You can do that by configuring the authentication provider in the mobile app code. For example, to add
an authentication provider such as Facebook, use the following section in the code in your MainPage.cs
project file:
user = await App.MobileService

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

Deploying mobile apps is not different from
deploying web apps. You can use several
deployment methods to deploy your mobile apps.
You can copy the files manually by using FTP or
you can synchronize the files and folders to App
Service from a cloud storage service, such as
OneDrive or Dropbox. App Service also supports
deployment from Web Deploy that is included in
Visual Studio, WebMatrix, and Visual Studio Team
Services.
From the Azure portal, you can download a starter

project for your mobile app. You can import this
project into Visual Studio 2015 and add custom code. When you complete the mobile app, you can
import a publishing profile into your project, as you did for a web app. You then can use this publishing
profile to deploy your completed mobile app to Azure by using the publishing wizard.
To deploy your project to Azure by using Visual Studio, perform the following steps:
1. In Visual Studio, open your project that contains the MVC application that you plan to deploy in
Azure.
2. In Solution Explorer, right-click your project, and then select Publish.
3. In the Publish Web dialog box, follow the Publish Web Wizard.
4. On the Profile tab, in the Select a publish target section, select Microsoft Azure App Service.
5. In the App Service dialog box, sign in to your Azure subscription, select your subscription, select a
resource group or create a new resource group, select an existing mobile app or create a new mobile
app, and then click OK.
6. On the Connection tab, select the publishing method to be Web Deploy, and then verify the site
name, user name, and the destination URL. You can click Validate Connection to verify the existence
of the new mobile app and the connectivity to the App Service. Click Next to proceed to next step.
7. On the Settings tab, verify that Release is selected from the Configuration drop-down menu, and
then click Next.
8. On the Preview tab, click Publish to begin the process of copying files to the Azure server.
9. Upon successful deployment, the default browser will automatically open the URL of deployed mobile
app.
Alternatively, you can use a Git repository to download starter projects for your mobile app source code.
The following is process of setting up continuous deployment:
1. Install Git from the official build http://git-scm.com/download/win.
2. Create a local repository, and then initialize by running the command git init.
3. Set the credentials to push the changes from your local repository.
4. Configure continuous deployment by providing the Git URL.
Demonstration: Implementing a mobile app

In this demonstration, you will learn how to create a new mobile app.
Demonstration Steps
1. In the Azure portal, create a new mobile app by specifying a unique valid URL.
2. Select an existing resource group or create a new group named AdatumMobileRG, and then select
the WebAppStandardPlan App Service plan.
3. Navigate to the newly created Mobile App. In the Quick start blade, choose Windows (C#) as the
language for the business logic code, and then click the Connect a database section.
4. In the Data connections blade, click Add.
5. In the Add data connection blade, select SQL Database, and then specify AdatumMobileDB as the
database name and choose S0 Standard as its pricing tier. Create a new SQL server with admin user
Instructor and password Pa$$w0rd.
6. In the Windows (C#) blade, under the Create a table API section, select C# as the backend
language.
7. Click the Download link, and save the compressed files on your computer. These files contain the
startup project that you can open in Visual Studio, develop the code, and then publish to Azure.
Question: Your company is developing a mobile app. You have been asked to host data and
notification hubs in Azure. What are the advantages of using a mobile app in Azure instead
of creating separate SQL databases and notification hubs?
Lesson 7
Traffic Manager
If you are running a large global web app, you might want to scale out the web app to multiple
datacenters. This helps in providing rapid response to user requests from a web server that is close to their
physical location. Alternatively, you might want to increase availability of your web app by providing
failover web apps that take over in case the primary web app has a problem. You can set up these
scenarios by using Azure Traffic Manager. In this lesson, you will learn how to configure and use Traffic
Manager to support highly responsive and available web apps.
Lesson Objectives
• Describe how Traffic Manager distributes requests to multiple web apps.
• Explain how to configure DNS prefixes and endpoints for Traffic Manager.
• Describe the best practices for a Traffic Manager configuration.
• Explain how to distribute requests to webs apps by using Traffic Manager.
Overview of Traffic Manager

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

load across app services that are located in
different Azure datacenters. You can do this
distribution by using Traffic Manager. Traffic
Manager provides load balancing by applying intelligent DNS queries between endpoints located in
different Azure regions. These endpoints can include cloud services that connect to virtual machines, PaaS
cloud services that connect to roles, and app services. You can configure load balancing to support
failover or to ensure that users connect to an endpoint that is close to their physical location for higher
performance.
How Traffic Manager works

A client resolves a FQDN to an IP address through Traffic Manager in the following way:
• The user requests a FQDN, for example by typing it into a browser address bar or by clicking a link. In
this example, the user requests www.adatum.com.
• In the DNS, the requested FQDN is forwarded to a traffic manager URL by using a CNAME record.
Administrators must configure such a record in DNS in order to use Traffic Manager with their own
domains. The traffic manager URL must be within the trafficmanager.net domain.
• Traffic Manager monitors the endpoints configured for the requested traffic manager URL. It returns
the IP address of one endpoint. The endpoint that it chooses depends on the load-balancing method
that you configure.
• The client receives the IP address and makes a connection to the web app’s endpoint.
Note: Traffic Manager can be used to distribute load across web apps, mobile apps, PaaS
cloud services, IaaS cloud services, public IP address, or external endpoints. Therefore, Traffic
Manager is useful for more than just web apps. In fact, it is a generic Azure service that you can
use to increase performance and availability for many endpoints within, and outside of, Azure.
How to implement Traffic Manager

The following are the steps to implement Traffic Manager:
1. Deploy endpoints that contain the same content and apps across different Azure datacenters.
2. Choose a domain prefix for your Traffic Manager profile that is unique.
3. Create a Traffic Manager profile with appropriate routing methods.

4. Add endpoints to your Traffic Manager profile to load balance the client requests.
5. Configure monitoring for your endpoints to identify that they are online and can serve client
requests.
6. Configure your company domain to point to your Traffic Manager profile.
You can configure Traffic Manager by using the classic deployment model and the Azure Resource
Manager deployment model. In the classic deployment model, Traffic Manager uses a load-balancing
method to decide how to distribute the client requests. In the Azure Resource Manager deployment
model, the same load-balancing method is known as the traffic routing method, which supports the
following three type of routing:
• Performance
• Weighted (round robin in the classic deployment)
• Priority (failover in the classic deployment)
Note: If you create Traffic Manager profiles by using classic deployment, they are not
available by using Azure Resource Manager, and vice versa.
You can configure three types of Traffic Manager endpoints:
• Azure endpoints that represent services hosted in Azure, such as web apps, cloud services, or public IP
addresses.
• External endpoint that are used to identify the services hosted outside of Azure, such as your web app
that is running at an ISP.
• Nested profiles that are used to implement nested hierarchies of different Traffic Manager profiles.
External endpoints
You can add an endpoint to a Traffic Manager profile even if that endpoint is external to Azure. For
example, consider the scenario in which A. Datum Corporation has a web app running at an ISP. You want
to move this web app into Azure, but because the web app is mission critical, you want to perform the
move in stages. You will add instances of the web app in Azure but want the ISP-hosted web app to
continue responding to requests. If the Azure instances fail, you want all web requests to be forwarded to
the ISP-hosted instance. You can build this configuration by adding the ISP-hosted web app as an external
endpoint to the Traffic Manager profile, which also includes the Azure web apps as endpoints.
To configure an external endpoint, use the New-AzureRMTrafficManagerProfile command and specify

the value ExternalEndpoint for type parameter.
In this example, the command adds an external endpoint to a performance-based Traffic Manager profile:
$profile = Get-AzureRMTrafficManagerProfile -Name "myprofile" –ResourceGroup AdatumRG

New-AzureRmTrafficManagerEndpoint –Name ExtEuro –ProfileName MyProfile –ResourceGroupName
AdatumRG –Type ExternalEndpoints -Target app-eu.adatum.com –EndpointStatus Enabled
Weighted routing method

If you choose the weighted routing method for your Traffic Manager profile, Traffic Manager distributes
the load approximately equally between the endpoints. If there are three endpoints in the profile, one
third of Traffic Manager responses will forward requests to the first endpoint. An equal proportion of
responses will forward requests to the second and third endpoints.
Note: Sometimes caching and other issues can distort the distribution of traffic. For
example, if a proxy server with a large number of clients caches a Traffic Manager response, all
clients that use that proxy server will connect to the same endpoint while that response remains
in the cache. However, if there are a large number of clients across the Internet, this distortion
tends to average out and the distribution of traffic becomes approximately equal.
Sometimes, however, you would prefer an unequal distribution of traffic. For example, if one endpoint is a
web app in the Standard tier, you can scale it more easily than a web app in the Basic tier. For such
situations, you can bias the distribution of load by specifying a weight for each endpoint. Endpoints with
larger weights receive more traffic. You can specify weights between 1 and 1,000. All endpoints have a
default weight of 1.
The following command adds a new endpoint with a specific weight to a Traffic Manager profile:
$endpoint = Get-AzureRmTrafficManagerEndpoint -Name myendpoint -ProfileName myprofile

-ResourceGroupName AdatumRG -Type ExternalEndpoints
$endpoint.Weight = 20
Set-AzureRmTrafficManagerEndpoint -TrafficManagerEndpoint $endpoint
Nested profiles
In most cases, a Traffic Manager endpoint is either a web or mobile app, a PaaS cloud service, or a virtual
machine in an IaaS cloud service. However, you can also specify a Traffic Manager profile as an endpoint.
This creates a nested profile, in which a parent profile contains one or more child profiles.
You can use this technique to increase the flexibility of load balancing. For example, you could set up a
parent profile that uses performance load balancing to distribute the load over several endpoints around
the world. Traffic Manager sends client requests to the endpoint that is closest to the user. Within one of
those endpoints, you could use round-robin load balancing in a child profile to distribute the load equally
between two web apps.
Configuring Traffic Manager

Before you can use Traffic Manager to distribute
the load to two or more app services, you must
create those apps in different locations and
deploy identical app content to all the sites. Both
content and configuration should be identical on
every app you use in a Traffic Manager set. After
you complete the deployment, perform the
following tasks to configure Traffic Manager:
1. Sign in to Azure portal.

2. On the Hub menu to the left, click New,
select the Networking link, and then click the
Traffic Manager profile link.
3. In the Create Traffic Manager profile blade, in the Name text box, type the unique name that will
be append with the trafficmanager.net domain.
4. Choose a routing method. You can choose from:
o Priority. Traffic Manager forwards all traffic to the first endpoint unless that endpoint is offline.
o Weighted. Traffic Manager distributes traffic equally between all endpoints.
o Performance. Traffic Manager forwards each request to the nearest endpoint to the client. This
increases performance because with endpoints located around the world, you can provide the
web app from a location close to the user.
5. In the Settings blade, click the Endpoints link.

6. In the Endpoints blade, click Add to add endpoints to the Traffic Manager profile. Each endpoint is a
web app in a different physical location.
7. In the Settings blade, click the Configuration link.
8. In the Configuration blade, you can change the routing method, define time to live (TTL) parameter
for the record, and configure monitoring. Traffic Manager polls each endpoint in the profile to
confirm that it is online. You can use TCP or HTTP for this monitoring. If you use HTTP, you can
specify a page that the Traffic Manager will request each time. You must ensure this page exists for
each endpoint in the Traffic Manager profile.
You can also configure Traffic Manager by using PowerShell. To configure, perform the following steps:
1. Start Azure PowerShell, and then sign in to your subscription by running the following command:
2. If you have multiple subscriptions, select the one in which you are going to create the Traffic
Manager profile by running the following command:
Set-AzureRmContext SubscriptionName “Name of your subscription”
3. Create a new resource group by running the following command:

4. Create the Traffic Manager profile with the name Myprofile. Use the Performance routing method
with the relative DNS name adatum. Provide a TTL value of 30 seconds and HTTP as the monitoring
protocol:
$profile = New-AzureRmTrafficManagerProfile –Name MyProfile -ResourceGroupName

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

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

Add-AzureRmTrafficManagerEndpointConfig –EndpointName webapp2ep
–TrafficManagerProfile $profile –Type AzureEndpoints -TargetResourceId $webapp2.Id
–EndpointStatus Enabled
7. Update the Traffic Manager profile with the changes by running the following command:
Set-AzureRMTrafficManagerProfile –TrafficManagerProfile $profile
Enabling and disabling endpoint and profiles

Certain configurations of Traffic Manager might require you to enable or disable some endpoints or
even the entire Traffic Manager profile. You can use the Enable-AzureRMTrafficManagerProfile or
Disable-AzureRMTrafficManagerProfile command to enable or disable a Traffic Manager profile. For
example:
Enable-AzureRmTrafficManagerProfile -Name MyProfile -ResourceGroupName AdarumRG

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

Disable-AzureRMTrafficManagerEndpoint commands.
Traffic Manager best practices

Follow these rules and best practices to ensure the
best resilience from Traffic Manager:
Best Practices:
• You must use a unique Traffic Manager prefix.

All Traffic Manager profiles must have a
FQDN within the trafficmanager.net DNS
domain. Ensure you choose a unique prefix
that is not already in use. The portal indicates
clearly when your chosen prefix is not unique.
• Keep in mind implications of changing the DNS TTL value. This value determines how often the web
browser’s local caching name server will query Traffic Manager for the IP address of the endpoint.
When you change any endpoints in a profile, it might take up to this time for changes to reach all
clients.
• Endpoints should all be in the same subscription. You can add endpoints to the Traffic Manager
profile in a different subscription, such as a partner organization’s subscription. You also can add
endpoints that are external to Azure. However, Traffic Manager will not remove external endpoints
automatically from the profile if they are deprovisioned. You must delete them manually.
• Remember that you can use only production endpoints. You cannot add staging slots to a Traffic
Manager profile. If you need to add staging slots, you can add them as external endpoints.
• Name endpoints clearly. Traffic Manager profiles can include many endpoints; administrators might
be confused if you do not ensure the endpoint names are descriptive and include the endpoint’s
location.
• Make endpoints consistent. If the content and configuration of all the endpoints in the Traffic
Manager profile are not identical, the response sent to users might be unpredictable.
• Disable endpoints for web app maintenance. You can perform maintenance operations on an
endpoint, such as updating a deployment, without causing any service interruptions by redirecting
the traffic to other endpoints. To do this, disable the endpoint you want to maintain before you begin
your administrative actions. Traffic Manager will forward all traffic to other endpoints until you finish
and reenable this endpoint.
Demonstration: Configuring Traffic Manager

• Create a new Traffic Manager profile.
• Add an endpoint to a Traffic Manager profile by using the Azure portal.
• Test Traffic Manager.
Demonstration Steps
Create a Traffic Manager profile

1. In the Azure portal, create a new Traffic Manager profile in the AdatumTMRG resource group.
2. Select Performance for the Routing Method and choose the Azure region closest to your location.
Add endpoints and configure Traffic Manager

1. In the Traffic Manager, add the web app endpoint representing the web app that you created in the
demonstration, “Deploying a Web App by using Web deploy.”
2. Set the TTL to 30 seconds.

Test Traffic Manager

1. Open a new Internet Explorer tab with the URL representing the new Traffic Manager profile. Verify
that Internet Explorer displays A. Datum’s web app.
2. From the Command Prompt, run the following command:
nslookup dnsname
Where dnsname is the DNS NAME of the Traffic Manager profile.
3. Note the aliases that are returned.
Question: How does the load-balancer solution of Traffic Manager differ from other similar
solutions that you can implement in Azure?
Lab: Implementing web apps

Scenario
The A. Datum Corporation’s public-facing web app currently runs on an IIS web server at the company’s
chosen ISP. A. Datum wants to migrate this web app into Azure. You must test the Web Apps functionality
by setting up a test A. Datum web app. An internal team provides you with a test web app to deploy. You
must ensure that they can continue to stage changes to the test web app before deploying those changes
to the public-facing site. A. Datum is a global company, so you also want to test Azure Traffic Manager,
and show your organization’s decision makers how it distributes traffic to instances close to users of the
web app.
Objectives
• Create a new web app.
• Deploy a web app.

• Manage web apps.
• Implement Traffic Manager to load-balance web apps.
Lab Setup
User name: Student
Password: Pa$$w0rd
Before you begin this lab, ensure that you perform the “Preparing the Azure environment” demonstration
tasks at the beginning of this module’s first lesson, and that the setup script is complete.
Exercise 1: Creating web apps

Scenario
You must set up a test web app in Azure. As the first step in the setup process, you want to create a new
web app. Later in this lab, you will deploy this web app to the test web app.

1. Create a web app.
2. Add a deployment slot.
3. Configure deployment credentials.
 Task 1: Create a web app

1. Ensure that the MSL-TMG1 and 20533C-MIA-CL1 virtual machines are running, and then sign in to
20533C-MIA-CL1 as Student with the password Pa$$w0rd.
2. In Internet Explorer, browse to http://portal.azure.com, and then sign into the portal by using a
Microsoft account that is either the Service Admin or co-admin of your subscription.
3. To create a new web app, use the following information:
o App name: any unique valid server name
o Resource Group: AdatumLabWebRG
o Web Hosting Plan Name: WebAppStandardPlan
o Pricing tier: S1 Standard
o Location: a location near you
 Task 2: Add a deployment slot

• In the Azure portal, add a new deployment slot to the web app that you created in the first task,
using the following information:
a. Name: Staging
b. Configuration Source: Choose the web app you created in Task 1
2. Open Azure PowerShell window and sign in to the Azure subscription with a Microsoft account
that is either the Service Admin or co-admin of your subscription.
3. If you have multiple subscriptions, select the target one by running the Azure PowerShell
Set-AzureRmContext cmdlet.
4. Use the Azure PowerShell Get-AzureRMWebApp and Get-AzureRMWebAppSlot cmdlets to
identify the web app and staging slot that you created.
5. Keep the Azure PowerShell window open.
 Task 3: Configure deployment credentials

• Use the Settings blade to set the following deployment credentials for the web app that you created
in the first task:
o FTP/Deployment User Name: ftpadminXXXX (replace XXXX is a unique number)

Results: After completing this exercise, you should have:

• Created a new web app in the Azure portal.
• Configured the new web app with deployment slots and credentials.
Exercise 2: Deploying a web app

Scenario
Now that you created a web app in Azure, and added a deployment slot for the web app, you can publish
the internally developed web app that the A. Datum web-development team supplied. In this exercise,
you will use a publishing profile in Visual Studio 2015 to connect to the new web app and deploy the web
content.
1. Obtain a publishing profile.
2. Deploy a web app.

 Task 1: Obtain a publishing profile

1. From the Azure portal, download the publish profile for the Web app you created in Exercise 1.
2. Open the following web-application project in Visual Studio 2015:
o D:\LabFiles\Lab05\Starter\AdatumWebsite\AdatumWebsite.sln
3. Start debugging the web application, examine the contents, and then close Internet Explorer.
Note: When you start the web application in Visual Studio, the web app runs in IIS Express on
your local workstation.
 Task 2: Deploy a web app

1. In Visual Studio, start the Publish Wizard for the AdatumWebsite project, and then import the
.PublishSettings file that you downloaded in Task 1 of this exercise.
2. Verify that the publish settings file includes correct connection information.
3. Ensure that the Release configuration is used for the published web app.
4. Preview the file changes, and then Publish the new website to Azure.
Note: The publish operation may take approximately two to three minutes. When the
operation is complete, Microsoft Edge opens and displays the new web app hosted in Azure.
5. Verify that A. Datum’s web app is open in Microsoft Edge, and then verify the web app’s current
address.
6. Close the Home Page tab.

Results: After completing this exercise, you should have a deployed a web app hosted in Azure that you
can open with any common web browser.
Exercise 3: Managing web apps

Scenario
The web-deployment team created an updated style sheet for the A. Datum’s test web app. You have to
demonstrate to the decision makers how you can deploy these changes to a staging slot, and then test
them, before you deploy to the production A. Datum web app. In this exercise, you will upload the new
web app to the staging slot that you created in Exercise 1, and you then will move the new site into the
production slot.
1. Deploy a web app for staging.
2. Swap deployment slots.
3. Roll back a deployment.

 Task 1: Deploy a web app for staging

1. In the Azure portal, download a publishing profile for the Staging slot for your web app.
2. Open the following project in Visual Studio:
D:\LabFiles\Lab05\Starter\NewAdatumWebsite\AdatumWebsite.sln
3. Publish the new web app, and then import the staging publish settings file that you just downloaded.
4. Validate the connection, and then choose the Release configuration.
5. Publish the new web app to the Staging slot.
6. Close Internet Explorer and Visual Studio.
 Task 2: Swap deployment slots

1. In Internet Explorer, access the web app that you created in Exercise 1.
2. Notice that the color scheme has not changed, because the Web app with the new color scheme is
still in the staging slot. Close the A. Datum web app.
3. From the Settings blade of your web app, open the Deployments Slots blade, and swap the staging
and production web-app slots.
4. When the swap completes, browse the web app, and notice that the color scheme is new.
5. Close the tab that displays the A. Datum’s web app.
 Task 3: Roll back a deployment

1. In the Azure portal, swap the staging and production slots again.
Note: By swapping the slots a second time, you simulate a deployment rollback.
2. When the swap is complete, browse the web app. Notice that the color scheme is reverted to the old
scheme.
3. Close the A. Datum tab in Internet Explorer.
Results: After completing this exercise, you should have an updated web app staged and published in
Azure.
Exercise 4: Implementing Traffic Manager

Scenario
Because A. Datum is a global brand, you must ensure that the A. Datum web apps respond rapidly to
requests from multiple locations around the world. You must evaluate Traffic Manager to see if it can
ensure web content is served from a location that is close to users. You have to set up Traffic Manager to
serve content from two different Azure regions.
1. Deploy a web app to another region.
2. Create a Traffic Manager profile.
3. Add endpoints, and configure Traffic Manager.

4. Test Traffic Manager.
5. Reset the Azure environment.
 Task 1: Deploy a web app to another region

1. In Azure PowerShell, obtain a list of all the web apps in your Azure subscription by using the
Get-AzureRMWebApp cmdlet. Note the name of your original web app and location.
2. Choose an Azure region that is different from the location of the original web app. This will become
the “SecondLocation”.
3. Use the New-AzureRMResourceGroup cmdlet to create a new resource group named

AdatumLabWebRG2.
4. Use the New-AzureRMAppServicePlan cmdlet to create a new App Service plan named
StandardPlan with Standard pricing tier in the resource group AdatumLabWebRG2 and the
“SecondLocation”.
5. Use the New-AzureRMWebApp cmdlet to create a new web app. Use the following information for
the web app:
o Resource group: AdatumLabWebRG2

o Name: Use the name of your original web app with the number 2 appended.
o Service plan: StandardPlan
o Location: “SecondLocation”.
6. In the Azure portal, download a publishing profile for the web app you just created (WebappName2).
7. Open the following project in Visual Studio:
D:\LabFiles\Lab05\Starter\AdatumWebsite\AdatumWebsite.sln
8. Start the Publish Web Wizard, and then import the publish settings file that you just downloaded.
Note: Be sure to add a new publish settings file on the Profile tab, so that you can publish
its content to the new web app.
9. Validate the connection, and then choose the Release configuration.
10. Publish the web app, and then close Internet Explorer and Visual Studio.
 Task 2: Create a Traffic Manager profile

• In the Azure portal, create a new Traffic Manager profile by using the following information:
o DNS Prefix: Use unique domain name
o Routing Method: Performance
o Resource Group: AdatumLabTMRG
 Task 3: Add endpoints, and configure Traffic Manager

1. Use the Settings blade of the Traffic Manager profile to add the web apps that you created in
Exercise 1 and Exercise 4 as endpoints.
2. In the Settings blade, use Configuration link to configure the DNS TTL value to be 30 seconds.
 Task 4: Test Traffic Manager

1. Use the DNS name listed in the newly created Traffic Manager profile in the Azure Portal to browse to
the corresponding URL by using Internet Explorer.
2. Use the nslookup command to resolve the DNS name for your Traffic Manager profile.
Note: In the DNS aliases, Traffic Manager returns the web app you created in Exercise 1,
which is the closest to your physical location.
3. In the Azure portal, disable the Traffic Manager endpoint that is the web app you created in
Exercise 1.
4. Use the nslookup command to resolve the DNS NAME for your Traffic Manager profile. The results
should differ from those in step 2.
Note: If the aliases are not changed, reissue the nslookup commands until there is a
change.
 Task 5: Reset the Azure environment

Reset-Azure
subscription.
Note: This script may remove Azure services in your subscription. Therefore, we
The script will take approximately two or three minutes to reset your Azure environment, so that
you are ready for the next lab. The script removes all storage, virtual machines, virtual networks,
cloud services, and resource groups.
Important: The script may not have exclusive access to a storage account so that it can delete it.
If this occurs, you will see an error message. If you find objects remaining after the reset script is
complete, you can rerun the Reset-Azure script, or use the Azure portal to delete all objects in
your Azure subscription manually, with the exception of the default directory. Do not delete it.
Results: After completing this exercise, you should have a web app set up in two Azure regions and Traffic
Manager configured to distribute requests between them.
Question: In Exercise 2, you deployed the A. Datum production web app to Azure. In
Exercise 3, you deployed a new version of the site to a staging slot. How can you tell, within
Internet Explorer, which is the production site and which is the staging site?
Question: At the end of Exercise 4, you used an FQDN within the trafficmanager.net domain
to access your web app. How can you use your own registered domain name to access this
web app?

Review Question
Question: What are the advantages of deploying a web app to Web Apps versus deploying
a website to an Azure virtual machine that is running IIS?
6-1
Module 6
Planning and implementing storage, backup, and recovery
services
Contents:
Module Overview 6-1
Lesson 1: Planning storage 6-2
Lesson 2: Implementing and managing Azure Storage 6-10
Lesson 3: Implementing Azure content delivery networks 6-22
Lesson 4: Implementing Azure Backup 6-27
Lesson 5: Planning and implementing Azure Site Recovery 6-34

Lab: Planning and implementing Azure Storage 6-40
Module Overview
Microsoft Azure Storage services provide a range of options for storing and accessing data. The core
services consist of four storage types: blobs, tables, queues, and files. Additionally, Microsoft Azure offers
storage capabilities to facilitate recovery and to assist customers with implementing their business
continuity and disaster recovery objectives. These services include Azure Backup and Azure Site Recovery.
Azure Content Delivery Network (CDN) is another storage-related service whose primary goal is to
improve the performance of web applications and services by hosting data in locations that are close to
consumers.
IT professionals can provision and manage Azure Storage services by using several tools and interfaces,
including the Azure portal, Azure PowerShell, and open source and third-party command-line and
graphical utilities. In this module, you will learn about the available data storage options and their
management.
Objectives
• Choose appropriate Azure Storage options to address business needs.

• Implement and manage Azure Storage.
• Improve web application performance by implementing Azure content delivery networks.
• Protect on-premises systems and Azure virtual machines (VMs) by using Azure Backup.
• Describe Azure Site Recovery capabilities.

6-2 Planning and implementing storage, backup, and recovery services
Lesson 1
Planning storage
Azure Storage Azure Backup, and Azure Site Recovery enable you to store and protect business data in
the cloud. With several different available storage options, it is important to understand not only how to
implement them, but also how to identify the one that is most appropriate for your storage needs.
Because storage is a billable commodity, you also need to be aware of its cost implications to deploy the
most cost-efficient solutions. This lesson discusses the various data services that are available in Azure, and
it outlines factors to consider when choosing between them.
Lesson Objectives
• Explain how to plan storage.
• Explain how to implement and manage Azure Storage.

• Explain how to implement Azure Content Delivery Networks.
• Explain how to implement Azure Backup.
• Describe how to plan and implement Azure Site Recovery.

• Start Windows PowerShell as Administrator.
• Run Setup-Azure.
• Specify the module number, and then confirm your selection.

• Sign-in to your Azure subscription.
• Select the Azure region to use during the demonstration and lab.
Important: The scripts that are used in this course might delete any objects that you have
in your subscription. For this reason, you should use a separate Azure subscription for this course.
Additionally, to avoid potential confusion, you should use a dedicated Microsoft account that is
not associated with any other Azure subscription.
The demonstrations and labs in this course use custom Windows PowerShell modules, including
Setup-Azure, to prepare the environment for a demonstration or a lab, and Reset-Azure performs
clean-up tasks afterward. For this module, Setup-Azure first creates an infrastructure as a service (IaaS) v1
storage account and an IaaS v1 virtual network named ADATUM-HQ-VNET in the region that you specify.
Next, it deploys an IaaS v1 virtual machine named AdatumSvr1 using the storage account to store its disks
and residing in the newly created virtual network. Afterward, the script removes any cached Azure
subscription and account information from the Azure PowerShell session.
classroom location. You will need this information during the lab setup and during the lab.
Demonstration Steps
1. Start Windows PowerShell with Administrator privileges.
Setup-Azure
5. When prompted, sign in to your Azure subscription by using an account that is a Service
6. When prompted, provide the number that corresponds to the Azure region that you want to use for
the Azure services that this script creates.
Note: The script will take about 10 minutes to complete.
Storage as an Azure component

Azure Storage is part of Azure data management
services, in addition to the backup and recovery
features. Several Azure services use Azure Storage,
including IaaS virtual machines, App Service, and
platform as a service (PaaS) cloud services. This
course covers these Azure services in detail.
Azure Storage is available in both the Service

Management (IaaS v1) and Azure Resource
Manager (IaaS v2) deployment models. Effectively,
you can create two types of storage, depending
on the deployment model that you choose. To
some extent, the deployment model that you
choose affects the usage. For example, you cannot use IaaS V1 storage to host IaaS V2 virtual machine
disks or images, just as you cannot use IaaS V2 storage to host disks or images of IaaS V1 virtual machines,
including disks that PaaS cloud services use.
Your choice of storage also has other usage implications. In particular, at the time of writing this course,
some storage-related services, such as Azure IaaS VM-level backup, support only IaaS V1 virtual machines.
Microsoft is actively working on enabling this functionality for Azure Resource Manager–based services.
App Service, PaaS cloud services, and web applications that IaaS virtual machines host can benefit from
CDN, which provides globally distributed storage for their static content. This allows you to improve the
customer experience when accessing these services from remote locations by minimizing their response
time.
The content can include text files, script libraries, downloadable software, and media such as video and
audio files. In a CDN, content replicates to a large number of servers, which reside in a number of
locations around the world. When a user requests CDN-resident content, the request forwards to a CDN
server that is closest to the user’s location.
You configure CDN by using the Azure Content Delivery Network service. This service can cache content
from Azure blob storage, IaaS and PaaS cloud services, Azure App Service, Azure Media Services, or a
custom origin by using any web address that is accessible from the Internet.
Overview of Azure Storage

Azure Storage is a service that you can use to
store both unstructured and partially structured
data. Developers and cloud architects commonly
choose it to host data that App Service or PaaS
cloud services use, or they use it to facilitate data
exchange between components of Azure-based
solutions. IT professionals who deploy IaaS virtual
machines rely on Azure Storage for storing virtual
machine operating system and data disks, and for
hosting network file share contents.
In general, Azure Storage offers four types of

storage services, depending on the type of data
that they are designed to store:
• Blobs. These typically represent unstructured files such as media content, virtual machine disks,
backups, or logs. Blobs facilitate locking mechanism, ensuring exclusive file access that IaaS virtual
machines require. There are three types of blobs. The first one, known as a block blob, is optimized for
sequential access, which is ideal for media content. The second one, referred to as a page blob, offers
superior random access capabilities, which is best suited for virtual machine disks. The third one,
referred to as an append blob, applies to data append operations, without the need to modify existing
content. This works best with logging and auditing activities.
• Tables. These host nonrelational and partially structured content, which consists of multiple rows of
data with different sets of properties. In the context of Azure Table storage, these rows are referred to
as entities. Developers frequently implement table storage as the backend data store for App Service
or PaaS cloud services.
• Queues. These are temporary storage for messages that Azure services commonly use to
asynchronously communicate with each other. In particular, in distributed applications, a source
component sends a message by placing it in a queue. The destination component works though the
messages in the queue one at a time.
• Files. Similar to blobs, these provide storage for unstructured files, but they offer support for file
sharing in the same manner as traditional on-premises Windows file shares.
There are two tiers of page blob storage: Standard and Premium. Premium Storage offers superior
performance because of its reliance on solid-state drive (SSD) technology. A standard storage account
uses traditional hard disk drives.
Storage accounts
To use Azure Storage, you first need to create a storage account. Premium storage accounts are strictly for
page blob storage.
By default, you can create up to 100 storage accounts in a single Azure subscription; however, you can
increase this soft limit by opening a service ticket with Azure support. Each standard storage account is
capable of hosting up to 500 terabytes (TB) of data, while the maximum size of a premium storage
account is 35 TB. For each storage account, you must specify:
• Name. This defines the unique URL that other services and applications use to access a storage
account’s content. All such URLs include the “core.windows.net” domain suffix. The fully qualified
domain name (FQDN) depends on the type of storage that you want to use. For example, if you
designate the “mystorageaccount” storage account name, you can access its blob service via
http://mystorageaccount.blob.core.windows.net.
• Location. This designates the Azure datacenter where the primary instance of your storage account
resides. In general, you should choose a region that is close to users, applications, or services that are
consuming the storage account’s content.
• A replication option. To ensure resiliency and availability, Azure automatically replicates your data
across multiple physical servers. There are four replication schemes:
o Locally redundant. Your data replicates synchronously across three copies within a single facility
in a single region. Locally redundant storage (LRS) protects your data against server hardware
failures but not against a failure of the facility itself. This is the only option available for Premium
Storage accounts.
o Zone-redundant. Your data replicates synchronously across three copies that reside in two or
three facilities in a single region. Zone-redundant storage (ZRS) offers more resiliency than LRS;
however, it does not protect against failures that affect an entire region. More importantly, ZRS
can contain only block blobs, which makes it unsuitable for hosting IaaS virtual machine disk files,
tables, queues, or file shares.
o Geo-redundant. Your data replicates asynchronously from the primary region to a secondary
region. Predefined pairing between the two regions ensures that data stays within the same
geographical area. Data also replicates synchronously across three replicas in each of the regions,
resulting in six copies of storage account content. If failure occurs in the primary region, Azure
Storage automatically fails over to the secondary region. Effectively, geo-redundant storage (GRS)
offers superior resiliency over LRS and ZRS.
o Read-access geo-redundant. As with GRS, your data replicates asynchronously across two regions
and synchronously within each region, yielding six copies of a storage account. However, with
read-access geographically redundant storage, the storage account in the secondary region is
available for read-only access regardless of the primary’s status. This allows you to perform near
real-time data analysis and reporting tasks without affecting your production workload
performance.
Note that standard storage accounts are capable of hosting any storage service type, including three
types of blobs, in addition to tables, queues, and files, unless you designate them as ZRS. If you designate
a storage account as ZRS, it supports only block blobs. Premium Storage accounts support only the LRS
scheme and are limited to storing page blobs only.
Planning for standard Azure Storage

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

Azure standard storage account costs are calculated based on its usage. In general, four components
contribute to storage-related charges:
• Volume of regional egress traffic. Inbound data transfers to Azure are free, and outbound data
transfers from Azure datacenters are free for the first 5 GB per month. Above this level is banded
pricing. Effectively, when services or applications co-locate with their storage, Azure does not impose
charges for bandwidth usage between compute and storage resources. Data transfers incur extra cost
only if compute and storage reside in different regions.
• Transactions. A transaction represents a read or a write operation to or from a storage account.
Pricing is provided in a currency amount per 100,000 transactions.
• Capacity. Capacity represents the amount of used storage space. Charges are on a per-GB basis. In
the case of page blobs, for example, this means that if you create a new 100 GB virtual hard disk file
but use only 10 GB of its total volume, you will be charged for that amount regardless of how much
space was allocated.
• Replication scheme. LRS storage accounts are cheaper than ZRS accounts, which are cheaper than
GRS accounts; read-access geographically redundant storage accounts are the most expensive.
Additional Reading: For more information, refer to Azure Storage Pricing:

http://aka.ms/Mzo4x7.
Azure storage partitioning

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

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

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

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

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

Microsoft designed Azure Storage services mainly
to support custom applications and solutions.
Therefore, storage access operations typically
occur by relying on programmatic methods
invoked from custom code. These methods might
use the Azure SDK libraries or the representational
state transfer (REST) interfaces that developers can
call by using HTTP and HTTPS requests.
However, a large number of tools allow you to

examine and manage content of Azure storage
accounts without writing custom code. Common
examples of such tools include Windows
PowerShell cmdlets, the AzCopy.exe command-line utility, the Storage Explorer Windows app, and
Microsoft Visual Studio 2015.
Azure PowerShell storage cmdlets

You can use the following Azure PowerShell cmdlets to explore an Azure storage account’s content:
• Get-AzureStorageBlob. Lists the blobs in a specified container and storage account.

• Get-AzureStorageBlobContent. Downloads a specified storage blob.
• Get-AzureStorageContainer. Lists the containers in a specified storage account.
• Get-AzureStorageFile. Lists the files and directories in a specified storage account.
• Get-AzureStorageFileContent. Downloads a specified file from Azure file storage.

• Get-AzureStorageQueue. Lists the queues in a storage account.
• Get-AzureStorageShare. Lists the file shares in a storage account.
• Get-AzureStorageTable. Lists the tables in a storage account.
Azure PowerShell allows you to obtain more detailed information about Azure storage accounts than is
currently available from the Azure portal.
AzCopy.exe
AzCopy.exe is a command-line utility that can carrying out high-performance operations on Azure
storage, including uploads, downloads, and data copies to and from blob, table, and file storage.
Additional Reading:
For a detailed description of AzCopy.exe, including its command-line switches and example
commands, refer to Transfer data with the AzCopy Command-Line Utility: http://aka.ms/dc878m.
Storage Explorer
Storage Explorer is available through the CodePlex website, which Microsoft hosts to provide project
hosting for open source software. Storage Explorer is a Windows app that provides a graphical interface
for management of blobs, tables, and queues. At the time of writing this course, there is no support for
Azure files.
Additional Reading: To download Storage Explorer, refer to Azure Storage Explorer:

http://azurestorageexplorer.codeplex.com/.
At the time of writing this course, Azure Storage Explorer 6 is the most recent version of Azure Storage
Explorer. With this utility, you can manage:
• Containers
• Blobs
• Tables
• Queues
• Security
• Access level
• Shared Access Signatures
• Cross-origin resource sharing for blob containers)
Visual Studio 2015

If you installed the Azure SDK for Microsoft .NET in Visual Studio 2015, you can use its Server Explorer
window to access Azure storage accounts and to manage their content. Unlike the CodePlex Storage
Explorer, Server Explorer can also create storage accounts, in addition to managing storage components
within an account.
Additional Reading: To review the information for using Server Explorer for Visual Studio
2015, refer to Browsing and Managing Storage Resources with Server Explorer:
http://aka.ms/Bp4587.
Creating a storage account

You can create a storage account on the Azure
portal or by using the following Windows
PowerShell cmdlets: New-AzureStorageAccount
to create a classic storage account and
New-AzureRmStorageAccount to create an
Azure Resource Manager storage account. A
storage account name must contain between
three and 24 characters and include only
lowercase letters and digits.
When you create a storage account, Azure

generates the following endpoints for access to
four respective storage types:
• https://account_name.blob.core.windows.net/
• https://account_name.table.core.windows.net/
• https://account_name.queue.core.windows.net/
• https://account_name.file.core.windows.net/
To create a storage account on the Azure portal, follow these steps:
1. On the Azure portal, on the Hub menu on the left, click +NEW, and then click Data + Storage.
2. In the Data + Storage blade, click Storage account.
3. In the Storage account blade, select the Resource Manager or Classic deployment model, and then
click Create.
4. In the Create blade, type a unique Name within the core.windows.net domain. If the name that you
choose is unique, a green check mark appears.
5. Click Type, and then in the Choose storage account type blade, select Premium Locally
Redundant, Locally Redundant, Geo-Redundant, Read-Access Geo-Redundant, or Zone
Redundant.
6. Click Select to confirm your choice.
7. Choose a target subscription or accept the default one.
8. Disable or enable Diagnostics. This option is not available for Premium storage accounts.
9. Select an existing Resource Group or create a new one.
10. Click Location in the drop-down list box that designates an Azure region where the storage account
will be created.
11. Enable or disable the Pin to dashboard check box.
12. Click Create.

In Azure PowerShell, you can create a new Azure Resource Manager storage account by issuing the
following command:
Creating a new Azure Resource Manager storage account in Azure PowerShell

New-AzureRmStorageAccount –ResourceGroupName ‘MyResourceGroup’ -AccountName
mystorageaccount –Location ‘Central US’ –Type ‘Standard_GRS’
During account creation, Azure automatically generates two account access keys and four endpoints for
all storage services types.
Implementing blobs
Blobs store directly in the root container of the
storage account or within a container that is
created after the account is provisioned. You can
create blob containers by using any of the tools
that this lesson previously described.
Creating blob containers

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

$storageKey = (Get-AzureRmStorageAccountKey –ResourceGroup ‘myResourceGroup’
-StorageAccountName $storageAccount).Primary
$storeContext = New-AzureStorageContext -StorageAccountName ‘mystorageaccount’
-StorageAccountKey $storeKey
$container = New-AzureStorageContainer –Name ‘mycontainer’ -Permission Container -Context
$storeContext
Administrators can view and modify containers, in addition to uploading and copying blobs by using tools
such as AzCopy and Azure Storage Explorer, or they can use the following Azure PowerShell cmdlets:
• Get-AzureStorageBlobCopyState. Get the copy state of a specified storage blob.
• Remove-AzureStorageBlob. Remove the specified storage blob.
• Set-AzureStorageBlobContent. Upload a local file to the blob container.
• Start-AzureStorageBlobCopy. Copy to a blob.
• Stop-AzureStorageBlobCopy. Stop copying to a blob.

Implementing Azure file storage

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

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

$storageAccount = ‘mystorageaccount’
$context = New-AzureStorageContext -StorageAccountName $storageAccount -StorageAccountKey
$storageKey
#Create the new share

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

New-AzureStorageDirectory -Share $share -Path ‘mydirectory’
#Upload a file
Set-AzureStorageFileContent -Share $share -Source ‘C:\upload\instructions.txt’ -Path
‘mydirectory’
Using file shares

To access an Azure file share from an IaaS virtual machine or from on-premises locations via a site-to-site
virtual private network (VPN) or ExpressRoute, run the net use command. The following command will
map drive Z to the reports share, where the storage account is called “adatum12345” and the storage
access key is PlsDTS0oEJWWQ8YOiVbL5kvow0/yg==.
Mapping a drive to an Azure file share

net use z: \\adatum12345.file.core.windows.net\reports /u:adatum12345
PlsDTS0oEJWWQ8YOiVbL5kvow0/yg==
Implementing Azure table and queue storage

Typically, applications create tables and queues
programmatically. Applications also are
responsible for populating tables with entities and
writing messages to queues, and for reading and
processing that content afterward. As a storage
administrator, you have also the option to view
and manage tables and queues with tools such as
Azure Storage Explorer or Azure PowerShell.
For example, you could run the following code to

create a table:
Creating a storage table in Azure PowerShell

$storageKey
New-AzureStorageTable -Name ‘MyTable’ -Context $context
To create a new messaging queue, run the following commands:
Creating a storage queue in Azure PowerShell

$storageKey
New-AzureStorageQueue -Name myqueue -Context $context
Controlling access to storage

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

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

Get-AzureRmStorageAccountKey –ResourceGroupName ‘myResourceGroup’ StorageAccountName
‘myaccount’
Having two storage keys allows you to regenerate one of them without disrupting applications that
require continuous access to the storage account. For example, if you regenerate the primary key,
applications can still successfully authenticate if they reference the secondary key. Next, you can repeat
this process to regenerate the secondary key, starting with modifying your applications by pointing them
to the new primary key. To avoid application changes, you can store the storage keys in the Azure
KeyVault.
To regenerate access keys, use the Azure portal or run the New-AzureRmStorageAccountKey cmdlet:
Regenerating keys
New-AzureRmStorageAccountKey -KeyType Primary –ResourceGroupName ‘myResourceGroup’
-StorageAccountName myaccount
Shared access signatures

The automatically generated primary and secondary access keys provide full administrative access to their
respective storage account, which is not suitable for scenarios where you need to delegate privileges that
are more restrictive. To answer this need, Azure Storage also supports the shared access signature
authentication mechanism. shared access signatures-based authentication allows you to limit access to
designated blob containers, tables, queues, and file shares only, or even to narrow it down to individual
resources such as blobs, ranges of table entities, and files. Shared access signatures also offer the ability to
specify the set of operations that are permitted on these resources. Additionally, you can limit the validity
of shared access signatures authentication tokens by assigning a start and end date, and the time of the
delegated access.
Microsoft has recently introduced features to support Account shared access signature. This functionality
allows you to grant permissions to perform service-level operations, such as, creating blob containers or
file shares.
A shared access signature takes the form of a Uniform Resource Identifier (URI), which is signed with the
storage account key. An application or a user with the knowledge of that URI can connect to the
corresponding storage account resources and perform delegated actions within the period that the token
validity parameters defined.
Most commonly, applications rely on the REST API to generate shared access signature URIs.
However, you can also create them by using Windows PowerShell. For example, the
New-AzureStorageRmContainerSASToken cmdlet generates a shared access signature token
for a blob container in an Azure Resource Manager storage account.
Stored access policies

While shared access signatures allow you to narrow down the scope of privileges and duration of access
to content for an Azure storage account, their management presents some challenges. In particular,
revoking access was granted directly through a shared access signature requires replacing the storage
account keys with which its URI was signed. Unfortunately, such an approach is disruptive because it
invalidates any currently configured connections to the storage account.
To remediate this shortcoming, Azure Storage supports stored access policies. You define such policies on
the resource container level, including blob containers, tables, queues, or file shares, by specifying the
same parameters that you would otherwise assign directly to a shared access signature, such as
permissions or start and end of the token validity. After a shared access policy is in place, you can
generate shared access signature URIs that inherit its properties. Revoking policy-based shared access
signature tokens requires modifying or deleting the corresponding policy only, without affecting access
granted via storage account keys or shared access signature URIs that are associated with other policies.
Additional Reading: For more information about using shared access signatures and
stored access policies, refer to Shared Access Signatures, Part 1: Understanding the shared access
signature model: http://aka.ms/R96g60.
RBAC
An alternative approach to controlling delegated management of Azure Storage resources is to use RBAC.
While relatively limited at this point, it can play a supplemental role to the storage access control
mechanisms.
RBAC includes a few predefined roles that provide delegated access to Azure storage accounts, including
Reader, Contributor, Storage Account Contributor, and Virtual Machine Contributor. If these roles are not
flexible enough, you can define custom ones. Their definitions consist of a list of permitted and prohibited
operations and assignable scopes to which these operations apply.
Additional Reading: For more information about RBAC, refer to Azure Role-based Access
Control: http://aka.ms/Jq63oa.
Monitoring storage
Monitoring and diagnostics features are built into
the functionality of any standard Azure storage
account, allowing you to view, record, and analyze
its performance and utilization levels so that you
can adjust your storage design according to your
workloads’ demands. Note that monitoring and
diagnostics are not available for Azure Premium
Storage accounts.
Enabling diagnostics
The simplest way to enable diagnostics relies on
settings on the Azure portal. Diagnostics are
enabled by default, and when you create a new
standard storage account, you have the option to disable diagnostics by using an on/off switch on the
Create blade. Diagnostics collect aggregate and per-API metrics for blob, table, and queue storage, and
retains them for seven days. After creating a storage account, you can alter its diagnostics settings on the
Diagnostics blade, which you can access from the Diagnostics tile in the account’s Settings blade. If you
turn off diagnostics, existing data persists through the end of the retention period.
You can enable or disable diagnostics for an entire storage account, with the retention policy from 1
through 365 days, but you have the ability to specify metrics separately, and you can collect logs for blob,
tables, queues, and files:
• Aggregate metrics. This includes data such as the volume of ingress and egress traffic, availability,
latency, or percentage of successful access requests aggregated for the Blob, Table, Queue, and File
services.
• Per-API metrics. This includes data representing volumes of storage API operations aggregated for
the Blob, Table, Queue, and File services.
• Logs. These contain all storage operations for Blob, Table, Queue, and File services. This allows you to
diagnose the cause of poor performance or to identify unauthorized access attempts.
To modify diagnostics settings for an existing storage account, follow these steps:
1. On the Azure portal, on the Hub menu on the left, click Browse.
2. In the list of services, click Storage accounts.
3. In the Storage accounts blade, click the storage account that you want to configure.
4. In the Settings blade of the storage account, click Diagnostics.
5. If diagnostics are disabled, in the Diagnostics blade, click On below the Status label.
6. Select the check boxes next to the metrics or logs that you want to collect.
7. Use the slider at the bottom of the blade to set the number of days (from 1 through 365) to retain
diagnostics data.
8. Click Save.
Note that enabling diagnostics incurs a cost because collected data stores in the designated metrics tables
(and, in case of capacity metrics, in a designated blob) in the same storage account.
Managing analytics
After you enable diagnostics for a storage account, you should be able to display collected metrics in the
Monitoring lens in the storage account’s blade on the Azure portal.
To add a metric to the monitoring chart, follow these steps:

1. On the Azure portal, in the Monitoring lens of the account’s blade, click Edit.
2. In the Edit Chart blade, select the Time Range (past hour, today, past week, or custom).
3. In the drop-down list box below the Time Range section, select the storage service type for which
you want to display metrics (blob, queue, table, or file).
4. Select check boxes next to the individual metrics that you want to display in the chart.
5. Click Save.
You also can configure alerts for any storage resource based on the metrics that you are collecting. An
alert detects when the value of a metric that you designated satisfies the criterion that you defined. A
criterion includes a condition such as greater than, a threshold value that depends on the type of metric,
and a period. You can configure an alert to send an email to owners, contributors, or readers of the target
resource, in addition to sending an email to an arbitrary email address. Additionally, as part of the alert
definition, you can specify a Webhook, which designates an HTTP or HTTPS endpoint to which the alert
would be routed.
Perform the following steps to set up an alert:
1. In the storage account’s blade on the Azure portal, click the Monitoring lens.
2. In the Metric blade, click Add alert.
3. In the Add an alert rule blade, specify the:
o Resource. This is the name of the target resource (storage account and service type).
o Name. This is the name of the alert.
o Description. This is the description of the alert.
o Metric. This is the metric on which the alert is based.

o Condition. This is greater than, greater than or equal to, less than, less than or equal to.
o Threshold. This value corresponds to the condition that you specified.
o Period. This is the period during which a condition is evaluated (from 5 minutes through 6 hours).
o Email owners, contributors, and readers. This is a check box that needs to be enabled or disabled.
o Additional administrator emails. This is a text box in which you can specify one or more email
accounts.
o Webhook. This is the HTTP or HTTPS endpoint to which the alert will route.
4. Click OK.
Monitoring performance of Azure Premium storage accounts

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

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

• View logged events.
Demonstration Steps
Create a storage account

1. Ensure that you have signed in to MIA-CL1 as Student with the password Pa$$w0rd and that the
setup script that you ran in the previous demonstration to prepare the environment has completed.
2. Start Internet Explorer, and then browse to the Azure portal. When prompted, sign in by using the
Microsoft account that is the Service Administrator or Co-Administrator of your Azure subscription.
3. Create a new storage account with the following settings:
o Name: Enter a valid, unique name consisting of between 3 and 24 lower case characters or digits.
o Deployment model: Classic
o Performance: Standard
o Replication: Geo-redundant storage (GRS)
o Subscription: Your Azure subscription
o Resource group: make sure that +New appears in the drop-down list and then type
Demo-Storage in the New resource group name text box
o Location: Select the Azure region nearest to you
o Pin to dashboard: Clear the check box
4. Wait for the storage account to be provisioned.

5. In the newly created storage account, create a blob container named demo-container with the
private access type.
6. Use the Azure portal to view the primary and secondary access keys for the storage account.
7. Leave the Internet Explorer window open. You will use it later in this demonstration.
Use Windows PowerShell to upload blobs

1. Open the UploadBlobs.ps1 file in the D:\Demofiles\Mod06 folder in the Windows PowerShell
Interactive Scripting Environment (ISE).
2. From within the Windows PowerShell ISE session, use the Get-AzureAccount cmdlet to verify that
you are signed in to your Azure subscription. If this is not the case, sign in to your Azure subscription.
3. In the script, set the value of the $storageAccountName variable to the name of the Azure storage
account that you created in the previous task.
4. Review the script, noting that it:

o Declares a variable named $containerName that references the demo-container container that
you created in the previous task.
o Finds the folder where the script is stored and declares a variable named $sourceFolder that
references the data subfolder.
o Uses the Get-AzureStorageKey cmdlet to retrieve the access key for your storage account.
o Uses the New-AzureStorageContext cmdlet to create a storage context that connects to your
storage account by using the access key.
o Iterates through the files in the source folder and uses the Set-AzureStorageBlobContent
cmdlet to write each file as a blob in the container.
5. Run the script and monitor its output, showing that the three files in the D:\Demofiles\Mod06\data
folder uploaded the demo-container container in your storage account.
Note: If you get “The remote server returned an error: (404) Not Found.” message, the
storage account might not have completed provisioning. Wait a few minutes, and then try
steps 4 and 5 again.
6. Close Windows PowerShell ISE without saving any changes.

View blob storage in Visual Studio

1. Start Visual Studio 2015, and then from its interface, connect to your Azure subscription by using the
Tools menu.
2. From Server Explorer in the Visual Studio interface, view the demo-container blob container that you
created earlier in this demonstration. Verify that the container has the files that the Windows
PowerShell script uploaded in the previous task.
Configure monitoring and logging

1. In Internet Explorer, on the Azure portal, navigate to the Diagnostics blade of the newly created
storage account.
2. Enable diagnostics for the storage account.
3. Review the content of the Metrics blade after enabling diagnostics.
View logged events

1. In the Monitoring section of the storage account blade on the AzurePortal, add the Events tile.
2. Display the most recent events in the Events blade of the storage account.

Question
You need to provide a customer time-limited access to the content of a blob

container in an Azure Storage account. You must ensure that the access can be
revoked without affecting other customers who access the same storage account.
What should you do?
Give the customer the primary access key.
Give the customer the secondary access key.
Configure the container as public.
Give the customer a shared access signature.
Configure a stored access policy. Give the customer a shared access

signaturebased on the stored access policy.
Lesson 3
Implementing Azure content delivery networks
Azure provides CDN functionality, which decreases the time it takes to download web content by first
distributing it across multiple locations around the world and then delivering it from the location that is
closest to the consumer of that content. This lesson presents the concept and architecture of CDNs and
describes the process of implementing Azure content delivery networks.
Lesson Objectives
• Describe the purpose and functionality of CDNs.
• Describe CDN architecture.
• Explain how to cache blob content by using Azure content delivery networks.
• Explain how to cache cloud services content by using Azure content delivery networks.
• Explain how to use custom domain addresses with Azure content delivery networks.
Overview of CDNs
The delivery speed of Internet-resident content
is a key factor in satisfying consumers of media
and web-based applications. CDNs represent
collections of geographically distributed servers,
whose purpose is to ensure satisfaction by
delivering content that is close to its consumers.
CDNs offer a number of advantages:
• Improved user-experience, especially if users

reside in areas distant from the original
content location.
• Protection of published content from

distributed denial of service attacks. Azure content delivery networks include functionality that
detects such attacks. Providing multiple copies of content serves as an additional mitigating factor.
• Improved scalability by eliminating performance bottlenecks that are associated with hosting content
in a single location.
• Increased resiliency increases by eliminating a single point of failure. In particular, if one CDN node
becomes unavailable, content transparently retrieves from the next nearest node.
Note: CDNs are intended for static content. Dynamic content needs to be refreshed
constantly from the content provider, minimizing and potentially eliminating any associated CDN
benefits.
Additional Reading: For more information, refer to Using CDN for Azure:
http://aka.ms/Aaa7h4.
Azure content delivery networks automatically distribute to multiple, globally distributed points of
presence (POP).
Additional Reading: For the latest POP list, refer to Azure Content Delivery Network (CDN)
POP Locations: http://aka.ms/P70n6a.
CDN architecture
Azure content delivery networks cache content
from Azure Storage blobs, Web Apps, PaaS cloud
services, or locations that are not Azure-based on
globally distributed content servers.
To configure an Azure content delivery network,
you need to create a CDN profile, which serves as
a container for CDN endpoints. The profile
constitutes an administrative and billing unit
according to its pricing tier. The profile also
provides additional features, such as country
filtering, which includes blocking or allowing
access to cached content from designated
countries, and analytics reporting.
A CDN profile can contain up to four endpoints, and there is a limit of four CDN profiles per Azure
subscription. Each endpoint designates an origin of cached content by pointing to an Azure Storage blob,
a web app that is associated with a standard or premium App Service plan, a PaaS cloud service, an Azure
Media Services streaming endpoint, or a custom origin. A custom origin represents any public web
location that you can access by using HTTP or HTTPS.
For every endpoint, you can configure a number of settings, such as:
• Compression. This setting is either enabled or disabled.
• Query string caching behavior. This setting controls caching behavior, depending on whether the
request to the endpoint includes a query string. For example, by choosing cache every unique URL,
you can cache content from a URL ending with “page1.ashx?q=one” separately from the content
from a URL ending with “page1.ashx?q=two”. Alternatively, you can cache the same content for both
of these requests (ignore query strings) or ignore caching altogether (bypass caching for query
string).
• Protocols. This setting allows you to enable an endpoint for HTTP and HTTPS.
You can apply additional settings to an Azure Media Services streaming endpoint, such as the caching
policy.
Additional Reading: For more information, refer to CDN Caching Policy in Media Services
Extension: http://aka.ms/I8fro8.
When a user accesses content, Azure retrieves the content from the nearest endpoint if it is available. If
the content is not available, Azure retrieves it from the origin, and subsequently CDN endpoints cache it.
Creating CDN profiles and endpoints

To provision a CDN, you first need to create a CDN profile. To create a CDN profile, use the following
steps:
1. On the Azure portal, click New on the Hub menu on the left side.
2. In the New blade, click Media + CDN.
3. In the Media + CDN blade, click CDN.
4. In the CDN profile blade, specify the following:
o Name. Use a unique name in your current subscription and resource group.
o Location. This Azure region will host the profile.
o Resource group. This is a new or existing resource group.
o Pricing tier. sStandard (S1) or Premium (P1).
o Subscription. This is your current subscription that should host the profile.
o Pin to dashboard. Enable this if you want the CDN profile to appear directly on the dashboard.
5. Click Create.
To create a CDN endpoint within a CDN profile, follow these steps:
1. In the CDN profile blade, click + Endpoint.
2. In the Add an endpoint blade, specify the following:

o Name. This is a unique name in the azureedge.net Domain Name System (DNS) namespace.
o Origin type. This is Storage, Cloud service, Web app, or Custom origin.
o Origin hostname. This is the name of the host that represents the origin type that you selected.
This can be a name that displays automatically for Azure resources, an FQDN, or its
corresponding IP address for custom origins.
o Origin path. This allows you to specify a directory path to retrieve from the origin.
o Origin host header. This is designates the host header value that should be sent to the origin with
each request. This is useful if you host multiple virtual domains on a single target server.
o Protocol and origin port: HTTP with the default port 80 and HTTPS with the default port 443.
3. Click Add.
Caching content from Azure blobs

For a CDN to cache blobs, users must be able to
access the blobs anonymously. This effectively
means that blobs should reside in containers with
public access permissions.
When you configure a CDN endpoint that points

to a public container in an Azure storage account
as its origin, you effectively define a new URL to
access its blobs through CDN. For example, if
you have a storage account named
“mystorageaccount” with the “public” public
container, the origin would be designated by
the URL
http://mystorageaccount.blob.core.windows.net/public. When you create an endpoint, you need to
specify a unique name in the azureedge.net DNS namespace, which would in turn represent the CDN
cached content that is available at http://uniquename.azureedge.net/public.
A blob stays in the CDN cache for a period known as the Time to Live (TTL), which by default is seven
days. Therefore, if users access this content frequently in a seven-day period, the CDN will offer a
significant performance gain. If users access this content every 10 days, CDN would provide no
performance gains. You can define the TTL period by invoking REST APIs, a managed API, or by using
other storage management tools.
Caching content from cloud services and web apps

You can enable CDN access for cloud services and
Azure websites. As with blobs, a separate URL
generates in the azureedge.net DNS namespace,
including the custom, unique name that you
provide when defining the corresponding
endpoint.
You should avoid using CDNs for caching content

that changes often—the CDN continues to serve
cached content until its TTL expires, even if the
content in the source location has changed. The
cloud service must reside in the production
deployment. Additionally, you must make cached
content available through HTTP on port 80, which is automatically applicable to Web apps, and deliver it
from the /cdn folder.
Similar to blob-based endpoints, cached content from cloud services has a seven-day TTL by default. You
can modify this by specifying the clientCache setting in the web.config file in the /cdn folder. The setting
could include a custom TTL value for all objects in the /cdn folder. You can even customize TTL further by
assigning CDN caching properties programmatically to individual objects.
Additional Reading: For more information about TTL with cloud services, refer to How to
Manage Expiration of Cloud Service Content in the Azure Content Delivery Network (CDN):
http://aka.ms/Vx0qfy.
Using custom domains to access CDNs

In several scenarios, you might want to point to
CDN-cached content by using names in your own
custom DNS namespace. If that is the case, keep
in mind that the target names must include a
prefix, such as “www.adatum.com,” and they
cannot take the form of a root domain, such as
“adatum.com.”
To accomplish this, you need to create an alias

(CNAME) resource record at your domain
registrar, which represents an alias of the CDN
endpoint’s FQDN. The translation between the
two names is transparent to users and
applications.
When you map a custom domain name to your CDN endpoint, you can specify that Azure will use the
asverify subdomain to preregister your custom domain. This allows you to avoid temporary loss of service
while DNS records update.

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

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

folder-level backups with the Azure Backup
agent, and the Online Backup integration module for Windows Server 2012 R2 Essentials.
• Long-term storage for Data Protection Manager with the Azure Backup agent.
• Long-term storage for Windows application-level backups with Microsoft Azure Backup Server.
• Windows-based and Linux-based Azure IaaS VM-level backups with the Azure VM Backup extension.
Backup vault
Regardless of the backup functionality that you intend to implement, to use Azure Backup to protect your
data, you must first create a backup vault in Azure. The vault should reside in an Azure region that is close
to the physical location of the data, and in the case of Azure IaaS virtual machines, in the same region. A
vault is the virtual destination of your backups, which also contain configuration information about the
systems that Azure Backup protects. To protect a system, you have to register it with a backup vault.
Two resiliency options are available when creating an Azure Backup vault: locally redundant and geo
redundant. The first option is based on LRS block blob Azure Storage, consisting of three copies of backed
up content in the same Azure region. The second option is based on GRS block blob Azure Storage,
including three additional copies in another Azure region, providing an additional level of protection.
Note that you cannot change this option after you register the first of your systems for vault protection.
An Azure subscription can host up to 25 vaults. Each vault can protect up to 50 computers that run the
Azure Backup agent or the Online Backup integration module. Alternatively, if you back up Azure IaaS
virtual machines by relying on the Azure IaaS VM Backup extension, the vault can protect up to 200
computers. Note that there is no limit on the amount of data in the vault for each protected computer.
There also is no limit on the maximum retention time of backed up content. However, there is a restriction
on the size of each data source: about 54,000 GB for Windows 8, Windows Server 2012, and newer
operating systems. The maximum backup frequency depends on the configuration, with up to three
backups per day with Windows Server or the client Azure Backup agent, up to two backups with Data
Protection Manager or the Microsoft Azure Backup Server, and a single backup when using IaaS VM
extension–based setup.
All backups are encrypted at the source with a password that the customer chooses and maintains. There
are no additional charges for the traffic generated during backup, both ingress, into Azure and during
restore, egress, out of Azure.
File and folder backups with the Azure Backup agent

Azure Backup’s most basic functionality allows
you to protect folders and files on 64-bit Windows
Server and client operating systems, both on-
premises and in Azure. This functionality relies on
the Azure Backup agent, which is available for
download on the Azure Backup vault interface in
the Azure classic portal. You must install the agent
on every system that you want to protect, and you
must register it with the target vault.
To set up Azure Backup agent–based protection,
you must perform the following steps:
1. Create a backup vault in Azure by using the

Azure classic portal, the Azure portal, or Azure PowerShell. Specify the storage replication option
(locally redundant or geo redundant) for the vault.
2. Download the vault credentials. The download link appears on the DASHBOARD page of the Azure
Backup vault on the Azure classic portal. The Azure Backup agent uses vault credentials to register
with the vault during the installation process.
3. Download and install the Azure Backup agent on the DASHBOARD page of the Azure Backup vault
in the Azure classic portal. Choose the appropriate backup agent for the system that you want to
protect. In this case, you need to select the For Windows Server or System Center Data Protection
Manager or Windows Client option. When registering the local computer with the vault, you can
designate a password for encrypting backups.
4. Use the Azure Backup console to configure and schedule backups. After installing the agent, the new
console, whose interface closely matches the native Windows backup console, becomes available. This
allows you to select files and folders to back up and to schedule a backup directly to the Azure
Backup vault. You can also use Azure PowerShell to configure and initiate backup operations. After
you schedule a backup, you also have the option to run an on-demand backup.
Note: If the computer that you want to protect contains a large amount of data and you
have limited bandwidth in your Internet connection to Azure, consider using the Azure
Import/Export service to perform the initial backup. In this approach, you copy the data to back
up locally to a physical disk, encrypt it, and then ship the disk to the Azure datacenter where the
vault is located. Azure then restores the content directly to the vault, which allows you to perform
an incremental rather than full backup following the registration.
Additional Reading: You will complete these configuration tasks in the lab. For more
information, refer to Prepare your environment to back up Windows machines:
http://aka.ms/Aabdfe.
VM-level backup by using the Azure Backup VM extension

If the systems that you want to protect are
running the Windows or Linux operating systems
on Azure IaaS virtual machines, then in addition to
running Azure Backup agent–based backups, you
also have the option to perform a VM-level
backup. This process uses the Azure Backup VM
extension and offers some additional benefits,
including application consistency for Windows
virtual machines, support for Linux, and a higher
limit for the number of protected systems per
vault, which is 200 Azure IaaS VMs versus 50
protected systems with the Azure Backup agent.
On the other hand, this method has several limitations. In particular, the backup frequency limit is once
per day. Additionally, at the time of writing this course, VM-level backup is limited to IaaS V1 virtual
machines. It is also not available for the DS and GS virtual machines that use Premium Storage. However,
as a viable alternative, you can back them up by using other methods, such as a local backup agent for
files and folders and Azure Backup Server or Data Protection Manager for application, volume, and system
state backup.
You should also keep in mind that the restore process creates a new virtual machine that cannot retrieve
individual files or folders from a backup into an existing virtual machine. In turn, this implies that any VM-
level settings, such as network configuration, must recreate after the restore. To simplify such restores, you
can automate the restore process by using Azure PowerShell. In fact, you must use Azure PowerShell
when recovering Azure IaaS virtual machines that host Active Directory domain controllers or that have
more involved network configuration, such as including load balancing, multiple reserved IP addresses, or
multiple network adapters.
Setting up an Azure IaaS VM-level backup requires you to perform the following steps:
1. If you do not already have an existing, available backup vault, create a new one in Azure by using the
Azure classic portal, Azure portal, or Azure PowerShell. Specify the storage replication option—LRS
or GRS—for the vault. Note that you can use the same vault for protecting Azure IaaS virtual
machines with the Azure Backup VM extension and systems that run the Azure Backup agent.
However, the vault must reside in the same Azure region as Azure IaaS virtual machines.
2. Discover Azure IaaS virtual machines by using the DISCOVER button on the command bar on the
Register Items page of the Azure Backup vault in the Azure classic portal. This will identify all IaaS V1
virtual machines in the same Azure region that have not yet registered.
3. Register discovered Azure IaaS virtual machines by using the REGISTER button on the command bar
on the Register Items page of the Azure Backup vault in the Azure classic portal. This will install the
Azure Backup VM extension, preparing the operating system for future backups. Note that all virtual
machine extensions, including this one, rely on the virtual machine agent being present and
operational. The agent is included by default on any Azure IaaS virtual machine that deployed from a
gallery-based image, but you might need to add it manually when using custom images.
4. Protect registered Azure IaaS virtual machines by using the PROTECT button on the command bar on
the Register Items page of the Azure Backup vault in the Azure classic portal. This will display the list
of registered Azure IaaS virtual machines, from which you select the ones that you intend to back up.
Next, you have to specify an existing policy or create a new one that will specify backup frequency
and start times, in addition to determining their retention range.
Integrating Azure Backup with Data Protection Manager and Microsoft

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

results. Although Microsoft Azure Backup Server
provides the same set of features as DPM, it does
not offer tape backups and integration with other
System Center products. Azure Backup Server also
offers the same management interface as DPM. Effectively, by implementing Microsoft Azure Backup
Server, you gain enterprise-grade protection without requiring System Center licenses.
With both of these products, you can provide recovery for Linux and Windows operating systems that run
on-premises or in Azure, as long as an Azure Backup Server or DPM server resides in the same location.
DPM and Azure Backup Server support consistent application backups of the most common Windows
server workloads, including SQL Server, Office SharePoint Server 2013 or 2016, and Microsoft Exchange
Server. They also deliver superior efficiency and disk space savings because of built-in deduplication
capabilities.
It is important to remember that unlike the other Azure Backup agent–based methods, neither DPM nor
Azure Backup Server can back up data directly to an Azure Backup vault. Instead, they operate as disk-to-
disk-to-cloud solutions, using their local disks as the immediate backup target, and afterward, copying
data to Azure from the newly created backup.
To integrate System Center DPM with Azure Backup, you must perform the following steps:
1. If you do not already have an existing, available backup vault, create a new one in Azure by using the
Azure classic portal, Azure portal, or Azure PowerShell. Specify the storage replication option—LRS
or GRS—for the vault. Note that you can use the same vault for protecting Azure IaaS virtual
machines with the Azure Backup VM extension and systems that run an Azure Backup agent,
including System Center DPM.
2. Download the vault credentials. The download link appears on the DASHBOARD page of the Azure
Backup vault in the Azure classic portal. The Azure Backup agent uses the vault credentials to register
with the vault during the installation process.
3. Download and install the Azure Backup agent on the DASHBOARD page of the Azure Backup vault
in the Azure classic portal. Choose the appropriate backup agent for the system that you want to
protect. In this case, you need to select the For Windows Server or System Center Data Protection
Manager or Windows Client option. When registering the DPM server with the vault, you can
designate a password for encrypting backups. You can access these registration settings through the
Online option in the Management workspace of the DPM Administrator Console.
4. From the Protection workspace of the DPM Administrator Console, create a new protection group or
modify an existing one. Within the protection group settings, enable the Online Protection option.
Note that you must enable short-term protection by using local disks. While you cannot use tapes for
this purpose, you can additionally enable long-term protection to tape. As part of the protection
group configuration, specify an online backup schedule, online protection data, online retention
policy, and initial online backup methodology. Similar to the Azure Backup consoles, you can choose
between performing initial backup over the Internet and using the Azure Import/Export service to
copy it offline.
Deploying Microsoft Azure Backup Server requires that you perform the following steps:
1. If you do not have an existing, available backup vault, create a new one in Azure by using the Azure
classic portal, Azure portal, or Azure PowerShell. Specify the storage replication option—LRS or
GRS—for the vault. Note that you can use the same vault for protecting Azure IaaS virtual machines
with the Azure Backup VM extension and systems that run an Azure Backup agent, including System
Center DPM or Microsoft Azure Backup Server.
2. On a Windows Server 2012 R2 Datacenter system that will host Microsoft Azure Backup Server,
download the vault credentials. The download link appears on the DASHBOARD page of the Azure
Backup vault in the Azure classic portal. The Azure Backup Agent uses the vault credentials to register
with the vault during the installation process. Note that the Windows Server 2012 R2 Datacenter
system can reside on-premises or in Azure, depending on the location of the systems that you intend
to protect.
3. On the same server, download and install the installation files. You can access the download package,
which is over 3 GB in size, on the DASHBOARD page of the Azure Backup vault in the Azure classic
portal, via the For Application Workloads (Disk to Disk to Cloud) link.
4. Extract the download package content by running MicrosoftAzureBackupInstaller.exe, and then

start the setup process. Note that that product requires a local instance of SQL Server 2014 Standard.
You have the option of using the SQL Server installation media in the package or deploying an
instance prior to running the setup.
5. When prompted, provide the path to the vault credentials that you downloaded earlier. When
registering the Microsoft Azure Backup Server with the vault, you can designate a password for
encrypting backups.
6. Because Microsoft Azure Backup Server has the same administrative interface as the System Center
DPM, after the setup completes, the remainder of the configuration is equivalent to the one
referencing a System Center DPM, with the exception of tape backup–related settings.
Demonstration: Implementing Azure IaaS virtual machine backups

In this demonstration, you will see how to implement Azure IaaS virtual machine backups. by:
• Create a backup vault.
• Create a custom backup policy.

• Register an Azure IaaS V1 VM in the Azure Backup vault.
• Protect an Azure IaaS V1 VM in the Azure Backup vault.
Demonstration Steps
Create a backup vault

1. Start Internet Explorer, and then sign in to the Azure classic portal by using the Microsoft account
that is the Service Administrator or Co-Administrator of your Azure subscription.
2. Create a new Azure Backup vault with the following settings:
o NAME: Demo-BackupVault
o REGION: The same region that you chose when running Setup-Azure
3. Wait until the vault creates and its status lists as Active.
Create a custom backup policy

• In the Demo-BackupVault Azure Backup vault, create a new policy with the following settings:
o POLICY TYPE: Azure Virtual Machines
o POLICY NAME: DemoBackupPolicy
o BACKUP FREQUENCY: Daily 6:00 AM local time

Keep the default values for the other settings.
Register an Azure IaaS V1 VM in the Azure Backup vault

1. In the Demo-BackupVault Azure Backup vault, discover all IaaS V1 virtual machines for which the
IaaS VM-level backup is allowed.
2. Register AdatumSvr1 in the backup vault.
3. Verify that the registration completed successfully.
Protect an Azure IaaS V1 VM in the Azure Backup vault

1. Enable protection of AdatumSvr1 in the Demo-BackupVault Azure Backup vault with the policy set
to DemoBackupPolicy.
2. Verify that the AdatumSvr1 is protected.
Reset the demo environment

Reset-Azure
demos and labs in the next module.
directory.

Question
You need to perform an application-level backup and restore of a Windows Azure

IaaS virtual machine. What solution can you use?
Install an Azure Backup agent on the virtual machine.
Install an Azure Backup agent on a Microsoft System Center 2012 R2 Data

Protection Manager (Data Protection Manager) server. Install the DPM agent on
the Azure virtual machine.
Install Azure Backup Server. Install the DPM agent on the Azure virtual machine.
Install the Azure VM Backup extension on the Azure virtual machine.
Use the built-in Windows Backup feature.

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

• Identify the factors to consider when planning for Azure Site Recovery.
• Describe how to implement Azure Site Recovery.
Overview of Azure Site Recovery

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

premises location. You can host the secondary site
in another on-premises location, or you can
implement it in Azure. The latter scenario uses Azure Storage to host disks of virtual machines that
function as replicas of their on-premises counterparts. Incidentally, Azure site recovery also provides
assistance in scenarios where both sites exist in the cloud, although this applies to migration and not to
recovery scenarios.
Microsoft has significantly enhanced Azure Site Recovery since its inception. While replication and
orchestration initially was limited to pairs of on-premises Microsoft System Center Virtual Machine
Manager (Virtual Machine Manager) deployments, current functionality supports:
• Virtual Machine Manager virtual machine replication and recovery orchestration from one
on-premises location to another.
• Virtual Machine Manager virtual machine replication and recovery orchestration from one
on-premises location to Azure.
• Hyper-V virtual machine replication and recovery orchestration from one on-premises location to
another.
• Hyper-V virtual machine replication and recovery orchestration from one on-premises location to
Azure.
• Physical Windows-based and Linux-based server replication and recovery orchestration from one
on-premises location to another.
• Physical Windows-based and Linux-based server replication and recovery orchestration from one
on-premises location to Azure.
• VMware virtual machine replication and recovery orchestration from one on-premises location to
another.
• VMware virtual machine replication and recovery orchestration from one on-premises location to
Azure.
Azure Site Recovery uses Hyper-V Replica to replicate Hyper-V virtual machines. Unified Agent, in
combination with other InMage components, provides equivalent functionality for the replication of
physical servers and Linux servers, in addition to VMware virtual machines. Effectively, these underlying
technologies determine overall recovery capabilities, such as near-synchronous replication for Hyper-V
virtual machines (within the 30 second range) and VMware virtual machines, in addition to support for
application-consistent snapshots. These features help you meet your RPO.
You can orchestrate recovery by implementing recovery plans, which designate the order in which you
should bring protected systems back online following failover and failback. The plans support Azure
Automation, which Module 11 of this course details, in addition to manual steps. This provides a sufficient
level of flexibility to account for complex scenarios, while at the same time allowing you to reach your
RTO.
Azure Site Recovery also supports planned and test failover. Test failover is supposed to occur in a
network that is fully isolated from the primary site, giving you the ability to evaluate the outcome of
activating replicas of protected systems without affecting the production environment. To facilitate both
types of failover, you should carefully consider the network and storage requirements of the systems that
you intend to protect. For example, note that those systems will likely require functional Active Directory
Domain Services (AD DS) and DNS-based name resolution.
Planning for Azure Site Recovery

Planning for Azure Site Recovery is highly
dependent on the location of the disaster
recovery environment that you want to
implement and on the type of systems that you
intend to protect. You might need to consider
developing your disaster recovery plan in
numerous scenarios. Some examples might
include migrating Azure virtual machines between
regions or migrating virtual machine instances
from Amazon Web Services to Azure.
In particular, you will need to consider different sets of criteria in each of the following scenarios:
• Replicating Hyper-V VMs to Azure with Virtual Machine Manager. On-premises components to
consider include the Virtual Machine Manager server, Hyper-V servers, and Hyper-V-hosted VMs.
Azure components to consider include the Azure Site Recovery vault, Azure virtual networks, and
Azure Storage.
• Replicating Hyper-V VMs to Azure without Virtual Machine Manager. On-premises components to
consider include Hyper-V servers and Hyper-V-hosted VMs. Azure components to consider include
the Azure Site Recovery vault, Azure virtual networks, and Azure Storage.
• Replicating VMware virtual machines and physical servers to Azure. On-premises components to
consider include the Process server, a VMware vCenter Server, ESX servers, VMware-managed virtual
machines, Mobility service, and several additional third-party components. Azure components that
you must consider include Configuration server, Master target server, the Azure Site Recovery vault,
Azure virtual networks, and Azure Storage.
• Replicating Hyper-V virtual machines to a secondary datacenter (note that this requires Virtual
Machine Manager. On-premises components to consider include the Virtual Machine Manager server,
Hyper-V servers, and Hyper-V-hosted VMs. The only Azure component to consider in this case is the
Azure Site Recovery vault.
• Replicating Hyper-V VMs to a secondary datacenter with storage area network (SAN) replication. On-
premises components to consider in the primary datacenter include the Virtual Machine Manager
server, the SAN array, Hyper-V servers, and Hyper-V-hosted VMs. On-premises components to
include in the secondary datacenter include the Virtual Machine Manager server, the SAN array, and
Hyper-V servers. The only Azure component to consider in this case is the Azure Site Recovery vault.
• Replicating between on-premises physical servers or VMware virtual machines in primary and
secondary datacenters. On-premises components in the primary datacenter to consider include the
Process server, the VMware vCenter Server, ESX servers, VMware-managed virtual machines, and the
Unified Agent. On-premises components in the secondary datacenter to consider include the
Configuration server, the vContinuum server, and the Master target server. The only Azure
component to consider in this case is the Azure Site Recovery vault.
Additional Reading: For more information about various Azure Site Recovery architectural
designs, refer to How does Azure Site Recovery work?: http://aka.ms/Fmx868.
The choice of architecture will drive additional network considerations. In general, you need to keep in
mind that users of your applications and services must be able to connect and authenticate to them
following a planned failover. Similarly, you typically need to facilitate client connectivity (for the testing
purposes) and core infrastructure support following a test failover. This necessitates AD DS availability and
DNS to provide authentication and name resolution in both planned and test failover scenarios.
Additional Reading: For more information, refer to Network infrastructure considerations

for Site Recovery: http://aka.ms/Idi9ib.
Capacity planning
Capacity planning is a primary challenge, especially with Azure as the recovery site. Fortunately, Microsoft
provides assistance with this task in the form of the Azure Site Recovery Capacity Planner, which is
available at http://aka.ms/asr-capacity-planner-excel. This Microsoft Excel–based tool evaluates the
existing workloads that you intend to protect, and based on this analysis, it provides recommendations
regarding compute, storage, and network resources that are required to implement their protection.
The tool operates in two modes:
• Quick planning. This mode considers the averages of the compute and storage resources, including
the amount of changes to replicate.
• Detailed planning. This mode analyzes each workload at the VM-level.
Note that you are responsible for collecting relevant data; the tool simply handles the relevant
calculations afterward. To determine the amount of changes, use the Capacity Planner for Hyper-V
Replica tool, which is available at http://aka.ms/Emd537, assuming that Hyper-V hosts your workloads. If
you operate in a VMware environment, use the vSphere Replication Capacity Planning Appliance, which is
available at http://aka.ms/O5c871.
Additional Reading: For more information, refer to Plan capacity for virtual machine and
physical server protection in Azure Site Recovery: http://aka.ms/Ht4m7g.
Supported workloads
Azure Site Recovery can integrate with a number of Windows server applications, such as Exchange
Server, database availability groups, SharePoint, SQL Server (including AlwaysOn Availability Groups),
Microsoft Dynamics CRM, in addition to third-party server software from vendors such as Oracle, SAP,
IBM, and Red Hat. This integration considerably simplifies building recovery plans, which protect the
systems that host these products. Similarly, you can configure servers that host core infrastructure
components, such as AD DS or DNS, to replicate from a primary site to a secondary site, either
on-premises or in Azure.
Additional Reading: For more information, refer to What workloads can you protect with
Azure Site Recovery?: http://aka.ms/Ut2weu.
Azure virtual machine requirements

When hosting your production systems in a Hyper-V environment, you might want to keep in mind
differences between on-premises Hyper-V and virtualization platform characteristics in Azure. Fortunately,
because of continuous enhancements to Azure Site Recovery, these differences are much less significant
than in the past. For example, Windows-based Generation 2 on-premises Hyper-V virtual machines
automatically convert to Generation 1 when they replicate to Azure. Similarly, .vhdx files automatically
convert to the .vhd format.
Additional Reading: For more information about additional Azure Site Recovery
requirements, refer to Prepare for Azure Site Recovery deployment: http://aka.ms/Jobhgk.
Implementing Azure Site Recovery

Implementing Azure Site Recovery is a relatively
involved process. The implementation steps
obviously depend on the design, which in turn is
determined by the recovery scenario that you
chose as the most suitable for your organization’s
business continuity needs.
For example, consider the traditional Azure Site

Recovery deployment with the primary site
running in an on-premises Virtual Machine
Manager environment and a secondary site
hosted in Azure. In such a case, you need to
complete the following tasks:
1. Create an Azure Site Recovery vault in the Azure classic portal.
2. After the vault creates, on the DASHBOARD page of the recovery vault in the Azure classic portal,
generate and download the vault registration key. You need to use this key when installing Azure Site
Recovery Provider.
3. On the same DASHBOARD page, download the Azure Site Recovery Provider and install it on the
Virtual Machine Manager server. This component is responsible for orchestration functionality.
Following the installation, you will be prompted to run the Microsoft Azure Site Recovery Registration
Wizard, during which you need to provide the vault registration key. During the registration, enable
the Sync cloud meta data to site recovery portal option.
4. On the Azure classic portal, create a GRS Azure storage account in the same region where the Azure
Site Recovery vault is located.
5. On the DASHBOARD page of the recovery vault in the Azure classic portal, download the Azure Site
Recovery services agent, and then install it on every Hyper-V host that is part of the Virtual Machine
Manager cloud that you want to protect. This component is responsible for replication functionality.
Incidentally, the Azure Backup service uses the same component to copy data to an Azure Backup
vault.
6. On the PROTECTED ITEMS page of the recovery vault in the Azure classic portal, set up protection
for Virtual Machine Manager clouds. The clouds become visible in the Azure classic portal as a result
of enabling the Sync cloud meta data to site recovery portal option when installing the Azure Site
Recovery Provider on the Virtual Machine Manager server. Enabling protection involves designating
the Azure storage account where replicated virtual disk files will be stored, which you created in the
step 4 of this procedure. In addition, it involves specifying such settings frequency of replication and
application consistent snapshots, retention of recovery points, replication start time, or encryption.
7. On the NETWORKS page of the recovery vault in the Azure classic portal, configure network
mapping. Network mapping correlates on-premises VM networks with Azure virtual networks. This
allows you to maintain control over network connectivity of VMs following a failover, ensuring that it
matches their on-premises configuration.
8. On the PROTECTED ITEMS page of the recovery vault in the Azure classic portal, enable protection
for VMs that you want to include in your disaster recovery plan.
Additional Reading: For full details about each of these steps, refer to Set up protection
between an on-premises Virtual Machine Manager site and Azure: http://aka.ms/S5ozj3.
Azure online documentation provides detailed guidance regarding other implementation
scenarios.
After you configure protection of virtual machines, you should create a recovery plan, which can control
the failover sequence by dividing protected virtual machines into groups and by ordering the groups.
Virtual machines in the same group fail over in parallel while those in different groups fail over according
to their group number. This allows you to account for virtual machine dependencies.
You can use recovery plans to specify the scope of planned, unplanned, and test failovers. Additionally,
you can further extend and automate recovery plans by incorporating Windows PowerShell scripts or
Azure Automation runbooks.
Additional Reading: For more information, refer to Create recovery plans:

http://aka.ms/Oegdsj.
The Azure Resource Manager deployment model supports Azure Site Recovery, although, at the time of
writing this course, the Azure portal does not expose this functionality, and it requires using Azure
PowerShell.
Additional Reading: For a sample configuration of Azure Site Recovery by using Azure
PowerShell and Azure Resource Manager, refer to Azure Site Recovery using PowerShell and
Azure Resource Manager: http://aka.ms/Bko5xm.

Question
Which components do you have to implement to facilitate Azure Site Recovery

between a Virtual Machine Manager environment on-premises and Azure?
An Azure Site Recovery vault
An Azure storage account
An Azure virtual network
A Configuration server
A Master target server

Lab: Planning and implementing Azure Storage

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

• Use Azure file storage.
• Protect data with Azure Backup.
Lab Setup
User name: Student
Password: Pa$$w0rd
Before starting this lab, ensure that you have performed the “Preparing the environment” demonstration
tasks at the beginning of the first lesson in this module and that the setup script has completed.
Exercise 1: Creating and configuring Azure Storage

Scenario
A. Datum currently stores images for IT assets as files in a local folder. As part of your Azure evaluation,
you want to test storing these images as blobs in Azure so that a new Azure-based version of the asset
management application can easily access them.
1. Create a storage account.
2. Install AzCopy.
3. Use AzCopy to upload blobs.
 Task 1: Create a storage account

1. Ensure that you are signed in to the MIA-CL1 virtual machine as Student with the password
Pa$$w0rd and that the setup script that you ran in the “Preparing the environment” demonstration
has completed.
2. Use Internet Explorer to sign in to the Azure portal at https://portal.azure.com by using the
Microsoft account that is the Service Administrator or Co-Administrator of your Azure subscription.
3. Create a new storage account with the following settings:
o Resource group: make sure that +New appears in the drop-down list and then type
Asset-Management in the New resource group name text box
4. After the storage account creates, add a blob container named asset-images with private access.
5. Start the Windows PowerShell ISE as an administrator.
6. Open the ExampleCommands.ps1 code snippets in the D:\Labfiles\Lab06\Starter folder, and then
record the name of the storage account that you created in the previous task.
7. Leave the Internet Explorer window open. You will use it later in this lab.
 Task 2: Install AzCopy

1. Download and install AzCopy from http://aka.ms/AzCopy. Note that this page also includes
documentation and examples for using AzCopy.
2. Add the AzCopy installation path C:\Program Files (x86)\Microsoft SDKs\Azure\AzCopy to the
Path system environment variable.
3. Test the installation by running the following command at a command prompt:
AzCopy /?
4. Keep the Command Prompt window open for the next task.
 Task 3: Use AzCopy to upload blobs

1. On the Azure portal, identify the keys for your storage account, and then copy the primary access key
to the Clipboard.
2. In the Windows PowerShell ISE window, use AzCopy to copy all of the .png files in the
D:\Labfiles\Lab06\Starter\asset-images folder to the asset-images container in your storage
account. Use the code snippets in the ExampleCommands.ps1 script in the D:\Labfiles\Lab06
\Starter\ folder to help you during this exercise. Ensure that you copy your commands to the
Command Prompt window, and do not try to run them as Windows PowerShell commands. This
involves replacing all placeholders in the existing script with the corresponding values that represent
your storage account name and primary access key, and then running the following command:
AzCopy /Dest:https://<your storage account>.blob.core.windows.net/asset-images

/destkey:<your primary access key> /Source:asset-images
3. Wait for the command to complete, and then view the file transfer information that displays.
4. Close the Command Prompt window.
Results: At the end of this exercise, you should have created a new Azure storage account with a
container named “asset-images.”
Exercise 2: Using Azure File storage

Scenario
A. Datum currently stores invoices for IT assets in the Microsoft Word format in a local folder. As part of
your evaluation of Azure, you want to test the uploading of these files to a file share in your Azure storage
account to make it easier for users to access them from VMs in Azure.
1. Create a file share and upload files.
2. Access a file share from a VM.
 Task 1: Create a file share and upload files

1. Use Windows PowerShell ISE to create a Windows PowerShell script that:
o Uses the New-AzureStorageShare cmdlet to create a file share named “assets.”
o Uses the New-AzureStorageDirectory cmdlet to create a folder named “invoices” in the file
share.
o Uses the Set-AzureStorageFileContent cmdlet to upload each file in the
D:\Labfiles\Lab06\Starter\invoices folder to the invoices folder in the file share.
Note: You can edit FileShare.ps1 in the D:\Labfiles\Lab06\Starter folder if you prefer not
to write the script from scratch.
2. Run the script to upload the files.
3. Observe the script as it runs, and then view the output. When you finish, close Windows PowerShell
ISE without saving any changes.
 Task 2: Access a file share from a VM

1. Connect to the AdatumSvr1 VM in your Azure subscription by using the following credentials; the
setup script that you ran earlier in the module created this VM:
o User name: AdatumSvr1\Student
2. In the Remote Desktop session to AdatumSvr1, turn off IE Enhanced Security Configuration for
administrators. Use Internet Explorer to sign in to the Azure portal, and then copy the primary access
key for your storage account to the Clipboard.
3. At an administrative command prompt, type the following command to map a network drive to the
assets file share in Azure storage. Replace both instances of storage_account with the name of your
storage account, and then paste your access key in place of access_key.
net use z: \\storage_account.file.core.windows.net\assets /u:storage_account access_key
4. In the Command Prompt window, enter the following command to view the contents of the invoices
folder in drive Z, which is now mapped to the assets file share that you created in the previous task:
dir z:\invoices
5. Verify that three invoice files are listed.
6. Sign out of the AdatumSvr1 VM to end the remote desktop session.
Results: At the end of this exercise, you should have created a file share named “assets” that contains a
folder named “invoices.” This folder will contain three invoice documents and will be accessible on the
AdatumSvr1 virtual machine (VM).
Exercise 3: Protecting data with Azure Backup

Scenario
A. Datum currently uses an on-premises backup solution. As part of your Azure evaluation, you want to
test the protection of on-premises master copies of your image files and invoices by backing them up to
the cloud. To accomplish this, you intend to use Azure Backup.
1. Create a backup vault.
2. Obtain vault credentials.
3. Install and configure the Azure Backup agent.
4. Create a backup schedule.
5. Run a backup.
 Task 1: Create a backup vault

1. In Internet Explorer, open the full Azure portal.
2. Create a new backup vault in your closest region.
 Task 2: Obtain vault credentials

1. On the Azure portal, click Recovery Services, and then click your new backup vault.
2. On the backup vault Quick Start page, click Download vault credentials.
3. Click Save to download the vault credentials to the Downloads folder.

 Task 3: Install and configure the Azure Backup agent

1. Download and install the Agent for Windows Server or System Center Data Protection Manager
or Windows Client.
2. Install any available updates for the backup agent.
3. Use the desktop shortcut that was created, start Azure Backup, and then register the server by using
the vault credentials that you downloaded earlier.
4. Generate a password, and then store it in the D:\Labfiles\Lab06\Starter folder.
5. Leave Azure Backup open for the next task.
 Task 4: Create a backup schedule

1. Use Azure Backup to schedule a daily backup to run at 4:30 AM, and then protect the following
subfolders in the D:\Labfiles\Lab06\Starter folder:
o asset-images
o invoices
2. Keep the defaults for the other backup settings.
 Task 5: Run a backup

1. Use Azure Backup to perform an on-demand backup.
2. On the Azure portal, verify that MIA-CL1 has registered, and then note the newest recovery point for
the protected items, which should include files and folders on drive D.

Reset-Azure
subscription.
5. When prompted for confirmation, press Y and press Enter.
groups.
directory.
Results: At the end of this exercise, you should have created an Azure Backup vault in your subscription,
created Azure Backup vault credentials, and installed the Azure Backup agent on the MIA-CL1 lab
computer. You should have backed up the contents of the asset-images and invoices folders to the
backup vault.

In this module, you have learned how to use Azure Storage, Azure Backup and Azure Site Recovery.
Review Question
Question: Why should you co-locate storage accounts and the Azure services that use them?
Best Practices
When using Azure Storage, consider the following best practices:
• Choose the most appropriate storage type based on your application requirements and the format of
the data to store.
• Co-locate storage accounts and the services that use them in the same region or affinity group.
• When storing blobs, use block blobs for large objects that you want to upload or stream, and use
page blobs when the application will read and write data in a random manner.
7-1
Module 7
Planning and implementing Azure SQL Database
Contents:
Module Overview 7-1
Lesson 1: Planning and deploying Azure SQL Database 7-2
Lesson 2: Implementing and managing Azure SQL Database 7-10
Lesson 3: Managing Azure SQL Database security 7-16
Lesson 4: Monitoring Azure SQL Database 7-24
Lesson 5: Managing Azure SQL Database business continuity 7-29
Lab: Planning and implementing Azure SQL Database 7-34

Module Overview
Microsoft Azure includes a range of services that you can use to manage data, including Microsoft Azure
SQL Database, which provides a relational database-management service based on Microsoft SQL Server.
You can use Azure SQL Database to implement a relational data store for applications, without having to
manage SQL Server or the operating systems that support it. In this module, you will learn about the
available data-storage and analysis options, and how you can provision, configure, and manage Azure
SQL Database.
Objectives
• Identify relational database services in Azure.
• Provision, configure, and manage Azure SQL Database.
• Configure security for Azure SQL Database.
• Monitor Azure SQL Database.

• Manage data recovery and availability for Azure SQL Database.
7-2 Planning and implementing Azure SQL Database
Lesson 1
Planning and deploying Azure SQL Database
Microsoft Azure provides multiple services that you can use to store, manage, and analyze data. The
service that you use depends on your application’s specific data-management requirements. This lesson
discusses the various data services that Microsoft Azure makes available, and what you need to consider
when choosing a data-storage solution.
Lesson Objectives
• Identify relational database services in Microsoft Azure.
• Choose between Azure SQL Database and Microsoft SQL Server.
• Describe the architecture of Azure SQL Database.
• Plan for the deployment of an Azure SQL Database.

2. Run the Setup-Azure command.
3. Specify the module number, and then confirm your selection.
Important: The scripts that this course utilizes might delete any objects that you have in
your subscription. For this reason, you should use a separate Azure subscription for this course.
Also, to avoid potential confusion, you should use a dedicated Microsoft account that has not
been associated with any other Azure subscription.
The demonstrations and labs in this course use custom Windows PowerShell modules, including Setup-
Azure to prepare the environment, and Reset-Azure to perform clean-up tasks afterwards. For this
module, Setup-Azure creates a database with sample data on the local SQL Server, and then removes
any cached Azure subscription and account information from the Azure PowerShell session.
Before you start, your instructor will decide which Azure region is the closest to your classroom location.
You will need this information during the lab setup and the lab.
Demonstration Steps
2. At the Windows PowerShell prompt, type the following command, and then press Enter:
Setup-Azure
4. Confirm your selection, and then press Enter. The script will take a few seconds to complete.
Relational database services as a component of Azure

Most business applications rely on a relational
database for data storage. Data takes the form
of a collection of two-dimensional tables that
represent real-life entities and relationships
between them. Table rows correspond to
individual instances of such entities, while table
columns describe their identifying properties. By
combining multiple interrelated tables, you can
express complex business scenarios and simplify
the analysis of their characteristics, so that you can
extract meaningful information about them.
When deploying relational databases to Microsoft

Azure, you can choose from the range of options spanning distinct services and product types. In general,
Microsoft Azure provides two basic types of relational database services, and each can support different
product types:
• Platform as a service (PaaS). This service, frequently referred to in this context as Database as a
Service, eliminates the requirement that you manage the underlying operating system and database-
server platform. This allows you to focus on database-specific tasks. The two commonly used offerings
in this category are:
o SQL Database, based on Microsoft SQL Server technologies.
o MySQL Database, based on the ClearDB MySQL Database cloud service, which is available from
the Microsoft Azure Marketplace.
• Infrastructure as a service (IaaS). You can create Azure IaaS virtual machines that host an instance of a
relational database-management system (RDBMS), such as SQL Server or MySQL. You also can use
any database server that is supported on any of the operating system platforms that you can deploy
within Azure IaaS virtual machines, including Oracle, DB2, or SAP HANA.
With Azure, you can migrate on-premises databases easily into the cloud, by hosting them on SQL Servers
that are running within IaaS virtual machines. This arrangement provides a familiar environment for
database administrators (DBAs). However, because this is an IaaS-based solution, you are responsible for
managing and maintaining all underlying software, including the operating system and database-
management system. You also are responsible for maintaining fault tolerance and scaling.
Microsoft provides a number of Azure PaaS-based alternatives to this approach, including the SQL
Database service. As a PaaS offering, this frees you from performing update and maintenance tasks, and
includes built-in features that provide fault tolerance and scalability. In this module, you will learn, in
detail, about SQL Database features, and you will step through the process of configuring it to support
your applications.
The Azure Storage feature includes table storage, but it is not suitable for relational data. Tables store
structured data in rows. However, Azure Storage does not have a rigid schema for each table. This means
each row in the table can have different columns, which is known as semi-structured data. For example, in
a Products table, a bicycle product might include a column for frame size, which a bicycle pedal product
does not include. Azure Storage tables also do not support cross-table relationships or multiple indexes,
both of which are necessary to facilitate efficient retrieval of relational data.
Note: It is important to note that there is a growing number of Azure services that offer
support for relational data, such as the:
• Azure SQL Data Warehouse, which is a fully managed relational-data warehouse as a service.
• Azure Data Factory Service, which provides data extraction, transformation, and loading functionality.
• Azure Data Analytics, which delivers analysis services based on any combination of unstructured,
semi-structured, and structured data.
Azure SQL Database vs. SQL Server in an IaaS virtual machine

When you use Microsoft Azure to implement a
Microsoft SQL Server-based database, you can
deploy it on a Microsoft SQL Server instance that
is running in an Azure IaaS virtual machine, or
deploy it as an Azure SQL Database. As you
determine which of these solutions is best for your
organizational needs, you should consider each
method’s characteristics, including:
• Manageability, maintenance, cost, and

provisioning speed. Azure SQL Database
constitutes a PaaS solution that removes
much of the overhead associated with
deploying and maintaining relational-database systems. The primary advantages of using Azure SQL
Database are that it minimizes your operating costs, reduces management complexity significantly,
and requires minimal provisioning time. Customers provision and manage SQL Server instances that
are running in Azure IaaS virtual machines as they would their on-premises counterparts, and their
pricing includes the cost of the dedicated virtual machine.
• Feature parity with on-premises SQL Server deployments. SQL Server instances that are running in
Azure IaaS virtual machines provide optimal compatibility with existing database applications.
Conversely, these applications might not be designed to take full advantage of Azure PaaS
capabilities. While you should be able to implement most common database workloads by using
Azure SQL Database, you need to consider that its behavior might differ in several aspects from
traditional SQL Server installations. Some of the features that Azure SQL Database does not support
currently include:
o Distributed transactions.
o The Service Broker feature and related objects.
o The SQL Server Profiler feature.
o Connectivity to an Object Linking and Embedding Database (OLE DB).
o Windows authentication; starting with version 12(V12), in addition to previously available

SQL Server authentication. Azure SQL Database also supports Microsoft Azure Active Directory
(Azure AD) authentication.
• Database isolation. One of the key principles of Azure SQL Database is strict database isolation. In a
SQL Server instance, applications can open a connection to one database, and then change the
database context (by invoking the USE T-SQL statement) or reference objects in a different database.
In Azure SQL Database, access is restricted to the database to which the connection was made
initially. Applications cannot change database context without opening a new connection.
• SQL Server components. SQL Server instance-level components—such as SQL Server Agent (and,
consequently, SQL Server Agent jobs), SQL Server Analysis Services, SQL Server Integration Services,
SQL Server Reporting Services, or Master Data Services—require a SQL Server instance running within
an Azure IaaS virtual machine. Note, however, that the absence of these components in Azure SQL
Database is more than compensated by a number of Azure services, such as Azure SQL Data
Warehouse or Azure Data Factory Service that provide equivalent functionality.
• Degree of collocation with other Azure services. Unlike Azure SQL Database, customers can collocate
a SQL Server instance that is running within an Azure IaaS virtual machine that is on the same Azure
virtual network as IaaS or PaaS cloud services. Depending on the intended architectural design, this
might be preferable to providing an additional level of integration or isolation in relation to other
Azure services and public networks.
• Licensing. Azure SQL Database is billed hourly at a fixed rate, depending on the service tier and
performance level that you decide to use. With SQL Server running in an Azure IaaS virtual machine,
you have two choices. The first one applies if you deploy a platform-provided SQL Server image. In
this case, your charges include its per-minute cost of SQL Server and Windows Server licensing, and
the cost of virtual-machine-persistent disks that are hosted in Azure blob storage. The second option
allows you to take advantage of the License Mobility clause in the Software Assurance agreement,
assuming that you have one, and apply your own SQL Server licenses to Azure-resident SQL Server
instances. Keep in mind that in this scenario, you should deploy a gallery Windows Server image or a
custom image that you uploaded to Azure to avoid double charges. These would apply if you deploy
a platform-provided SQL Server image.
• High availability and scalability. High availability and scalability features such as AlwaysOn Availability
Groups, database mirroring, replication, or table partitioning are supported in Azure only when using
a SQL Server instance that is running within an Azure IaaS virtual machine. However, you can
accomplish an equivalent level of resiliency and elasticity, with significantly less management
overhead, by capitalizing on the built-in characteristics of Azure SQL Database service. These built-in
characteristics include point-in-time restore, geo-restore, geo-replication, service tiers (scaling up), or
federations and sharding, which refers to scaling out by partitioning data horizontally. Traditionally
complex sharding has been considerably simplified with the introduction of the Elastic Database
feature of Azure SQL Database.
Note: Azure does not support SQL Server AlwaysOn Failover Cluster instances in an Azure
IaaS virtual machine, because there is no support for shared VHD storage in Azure virtual
machines.
Additional Reading: For a comprehensive list of features supported by SQL Databases,

refer to Azure SQL Database General Limitations and Guidelines: http://aka.ms/M7dnzz.
Additional Reading: For a comprehensive list of Azure SQL Database Transact-SQL

Differences, refer to Azure SQL Database Transact-SQL differences: http://aka.ms/Ps3svp.
Azure SQL Database architecture

Azure SQL Database is a PaaS relational-database
service that is based on SQL Server. SQL Database
provides a familiar relational-database solution
that implements many of SQL Server’s
fundamental capabilities, including tables, views,
stored procedures, and other database objects.
The goal of SQL Database is to deliver easily and

quickly provisioned databases that scale to meet
an organization’s needs while not requiring to
manage the operating system, hardware, and
database-management system. This allows
administrators to focus primarily on the logical
management of the database objects and its content.
From the perspective of the SQL Server developer or administrator, SQL Database operates much like a
traditional SQL Server instance. However, there are a few key distinctions, which the previous topic
detailed. You can write SELECT queries against tables and views, and invoke functions and stored
procedures against an Azure SQL Database, similar to a SQL Server-resident database.
Beyond the relational database engine provided by SQL Database, you must understand the model
behind the Azure platform, so you can set up your own account, provision a server, and create databases.
There is a relationship between four core objects in SQL Database, including the subscription, the resource
group, the server, and the database. The following table describes these objects.
Azure object Description
Azure subscription An Azure subscription constitutes the primary administrative, security, and
billing boundary. An Azure subscription can contain zero or more SQL
Database servers.
Resource group Resource groups are conceptual containers in which you can group related
Azure resources to further enhance manageability, security, and billing. You
can create your SQL Database resources in a single resource group, along with
other related resources (such as Azure web applications), that use a SQL
Database to store data. An Azure subscription can contain multiple resource
groups.
SQL Database SQL Database servers are logical servers that host SQL Databases. Each SQL
server Database server has a Domain Name System (DNS) name, administrator
accounts, and firewall rules. SQL Database servers can host zero or more user
databases in addition to the master system database, which stores server-
configuration data.
You can choose to organize SQL Database servers into resource groups to
facilitate delegation of administration and cost allocation. You can place
multiple database servers in each resource group. Note that, unlike resource
groups, SQL Database servers are bound to a specific Azure datacenter.
Azure object Description
SQL Database Databases in a SQL Database server, similar to databases in a SQL Server
instance, are containers for data objects, such as tables, views, functions,
procedures, and user security accounts. However, unlike a SQL Server instance,
SQL Database does not expose system databases, other than the master
database.
Each database is isolated from the others on the same server. Each SQL
Database server can contain multiple databases. Note that because each server
is bound to a specific Azure datacenter, all of its databases also effectively
reside in the same datacenter.
Planning the deployment of an Azure SQL Database

When you plan an Azure SQL Database
deployment, your primary consideration should
be the database’s intended workload. Your first
step should be to determine whether any service-
specific functional limitations would require that
you choose an IaaS-based implementation of SQL
Server or another relational database-
management system. Also, you should consider
the scalability limits of Azure SQL Database. These
might include maximum supported database size
(set to 1 terabyte (TB) at the time of this course’s
creation) or performance, with respect to
transactional throughput, maximum concurrent requests, maximum sessions, and maximum concurrent
logins.
Note: Note that you might be able to mitigate existing scalability limits by scaling out your
deployment. You can accomplish this by using the Elastic Database feature of Azure SQL
Database.
Another important decision you will need to make is to determine which method you will use to allocate
resources across instances of Azure SQL Database. In general, you have two choices, including:
• A traditional approach, which provides a dedicated set of resources for each database. It does this by
assigning a pricing tier to it, which determines its sizing and performance characteristics.
• A second approach, introduced in Azure SQL Database V12, which allows you to distribute resources
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 with a
single server only. 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. However, you can
configure minimum and maximum performance levels and database size. This allows you to ensure
that individual databases will not monopolize all of the resources allocated to its pool.
Elastic database pools yield cost savings if you have groups of databases with varying usage patterns,
where you can shift resources from one database to another, thereby addressing their individual
demands. You can use the Azure portal helps you in determining the optimal arrangement. The Azure
portal provides recommendation when allocating a database to a pool based on analysis of the database’s
performance.
Performance comparisons between the two models are simple because their respective measurements
units are equivalent. The relative power of individual databases is expressed in Database Transaction Units
(DTUs), which represent their capacity in terms of handling online transaction processing (OLTP) requests.
A database assigned 10 DTUs has approximately twice the capacity of a database with 5 DTUs. Similarly,
elastic database pools rely on elastic Database Transaction Units (eDTUs), which have the same meaning
as DTUs. Their only distinctive features are that they are assigned to a pool, rather than to a database, and
they are not consumed until there is a demand for them.
Projected workload analysis also will help you identify other configuration settings that you should specify
during the provisioning process, including:
• Service tier. Both single database deployments and elastic database pools support three service tiers,
including:
o Basic. Basic tier is sufficient for small development and testing databases or single user
applications.
o Standard. Standard is a common choice for most workgroup and web applications.
o Premium. Premium is intended for mission-critical applications that require high transactional
volume.
Each of them offers a 99.99 percent uptime service level agreement (SLA), predictable performance,
and hourly billing. They differ based on restore and disaster-recovery capabilities and parameters,
such as the:
o Maximum database size, ranging from 2 gigabytes (GB) to 1 TB for a single database deployment
o DTUs or eDTUs
o Maximum concurrent requests, sessions, and logins
o Maximum in-memory OLTP storage. In the case of elastic database pools, most of these
parameters are assigned on a per-pool basis
• Performance level. When dealing with single database deployments, within the Standard and
Premium service tier, you have the ability to define your capacity requirements further by specifying
the performance level. This does not affect the maximum supported database size or disaster-
recovery capabilities. They remain constant within each service tier. However, it does affect
performance characteristics. For example, within the Premium tier, the P1 performance level delivers
125 DTUs and up to 2,400 sessions, while the P11 performance level offers 1,750 DTUs and up to
32,000 sessions.
• Location. You should place the database as close as possible to the consumer of its content. This, in
turn, implies that you should deploy a logical SQL server to that location. Note that with elastic
database pools, all databases in a given pool must reside on the same server.
Keep in mind that regardless of your initial analysis, pricing tier (which represents the service tier and, in
case of individual database deployments, the performance level) can be easily changed without any
downtime.

Question
Which of the following features does the Azure SQL Database service support? Select
all that apply.
SQL Server Profiler
Distributed transactions
Windows authentication
Azure Active Directory Authentication
SQL Server authentication

Lesson 2
Implementing and managing Azure SQL Database
Azure SQL Database is a cloud-based SQL service that provides subscribers with a highly scalable platform
for hosting their databases. Organizations that use Azure SQL Database can avoid the cost and complexity
of managing on-site SQL Server installations, and quickly set up and start using database applications. In
this lesson, you will learn about provisioning and managing databases in Azure SQL Database.
Lesson Objectives
• Describe the tools for implementing and managing Azure SQL Database.
• Provision Azure SQL Database.
• Migrate SQL Server databases to Azure SQL Database.
• Connect SQL Server Management Studio to Azure SQL Database and use it to manage databases.
Tools for implementing and managing Azure SQL Database

In general, there are two sets of tools and
management interfaces that facilitate the
implementation and management of Azure SQL
Database. The first set of tools offers the ability to
manage Azure specific characteristics of the SQL
Database, including its deployment. This category
includes:
• The Azure portal. You can use the Azure

portal to provision Azure SQL Database
instances along with hosting the servers and
to manage their configuration settings such
as server firewall rules, pricing tiers, or
administrative credentials. From a management standpoint, it provides the interface for a variety of
administrative tasks, such as restoring databases from automatic backups, configuring database
auditing, and monitoring database performance metrics. However, the portal does not provide direct
access to database objects, such as tables or views, nor allow you to execute Transact-SQL statements.
• Azure PowerShell. While its functionality mostly overlaps with the Azure portal, it offers more
flexibility. For example, it allows you to provision a server without associating the Azure SQL Database
with it. Also, it facilitates automation, which minimizes administrative overhead.
• Azure command-line interface (Azure CLI). From the functionality perspective, this approach is
equivalent to the Windows PowerShell–based management, but you can use it to carry out
management tasks from computers running Windows, Linux, and Mac operating systems.
• Azure Resource Manager templates. With Azure Resource Manager templates, you have the option of
provisioning Azure SQL Database (along with its server) in the declarative manner.
The second set of tools deals with the database-specific functionality. In this category, you will find the
same utilities that have been traditionally used by on-premises database administrators, including:
• SQL Server Management Studio. You can use SQL Server Management Studio to connect to an Azure
SQL Database server and manage it, similar to a computer that is running SQL Server. The ability to
use the same tool to manage SQL Server instances and SQL Database servers is useful in hybrid IT
environments. However, some of the graphical designers in SQL Server Management Studio are not
compatible with SQL Database, which means that, in those cases, you will need to resort to executing
the Transact-SQL statements.
• SQLCMD. You can use the SQLCMD command-line tool to connect to Azure SQL Database servers
and execute Transact-SQL queries in the same way you could run these commands against SQL
Server-hosted databases.
• Visual Studio. Developers can use Visual Studio to create databases and deploy them directly to Azure
SQL Database.
Provisioning Azure SQL Database

You can provision Azure SQL Database services
either from the Azure portal or by using Azure
PowerShell module.
Creating a database
When you create a database, you need to specify
the following information (or accept the default
values):
• A name for the database.
• The service tier of SQL Database you want to

use, the desired performance level (expressed
in database throughput units), and the
maximum size you want the database to grow to. These settings determine the cost of the database.
• The collation that you want the database to use.
• 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 one.
• The resource group in which the database and its server should be created (if you select an existing
server, the database is automatically added to the existing resource group to which the server
belongs).
Creating a server
When using the Azure Portal, you can create a server during the creation of a database. If, however, your
intention is to create a new server without a database associated with it, you can accomplish this by using
the Azure PowerShell module. In scenarios where you are provisioning 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 migrating them from an on-premises SQL Server instance.
Each SQL Database server must have a globally unique name. The fully qualified name of the server is in
the form <server_name>.database.windows.net; for example, abcd1234.database.windows.net.
When you create a server, you must specify the following information:
• A globally unique server name.
• A sign in name and password for the administrative account that you will use to manage the server.
• The geographical region of the Azure datacenter hosting the server.
• Whether to allow other Azure services to connect to the server. Enabling access from Azure creates a
firewall rule that permits access from the IP address 0.0.0.0, which represents Azure services.
• Whether to create a V12 server.
Note: After you have created a server, you must configure its settings to allow incoming
connections based on the source IP address. Firewall rules are discussed in more depth later in
this module.
Migrating a SQL Server Database to Azure SQL Database

A common Azure SQL Database deployment
scenario involves migration of a database from a
SQL Server instance to a SQL Database server. You
would typically use this approach when migrating
on-premises applications to the cloud.
There are two primary techniques you can use to

migrate a database from SQL Server to Azure SQL
Database:
• Generate Transact-SQL scripts that capture

the definition of every object in your SQL
Server database and run them afterwards in
Azure SQL Database to generate their exact
duplicates.
• Export a data-tier application (DAC) from SQL Server and import it into Azure SQL Database. You can
export a DAC as a .dacpac file (containing database schema) or as a .bacpac file (containing database
schema and data).
Of these two techniques, using a DAC is the simplest way to ensure the correct migration of the database
and its content. You can export and import the DAC by using SQL Server Management Studio. The Export
Data-Tier Application wizard in SQL Server Management Studio allows you to specify an Azure Storage
account as the destination for an exported package. The Import Data-Tier Application wizard enables you
to specify an Azure Storage account as the source for the package that you want to import. This makes it
easy to migrate a database from SQL Server to Azure SQL Database in two stages, using Azure Storage as
an intermediary storage location for the DAC package. Alternatively, you can use the Deploy Database
wizard to export a SQL Server database as a DAC package and import it into an Azure SQL Database
server in a single operation.
Note: Whichever technique you use to migrate a SQL Server database to Azure SQL
Database, you will first need to resolve any compatibility issues, and then reconfigure security for
the database. Although DAC packages include logins and maintain mappings to database users,
the migration operation does not include passwords; you must reset these after the migration
completes. Additionally, if the source database uses Windows authentication, you will need to
create new logins and users at the target because SQL Database does not support Windows
authentication.
Demonstration: Implementing Azure SQL Database

• Create an Azure SQL Database.
• Configure server firewall settings.
• Connect to the Azure SQL Database by using SQL Server Management Studio.
• Configure a client connection string to Azure SQL Database.
Demonstration Steps
Create an Azure SQL Database

1. Ensure that the previous demonstration has completed successfully, and then sign in to the MIA-CL1
lab virtual machine as Student with the password Pa$$w0rd.
2. Launch Internet Explorer, and then sign in to the Azure portal by using the Microsoft account that is
the Subscription Administrator or Co-Administrator of your Azure subscription.
3. From the Azure portal, create a new SQL Database with the following parameters:
o Name: demodb
o SQL server:
 Server name: any valid unique name
 Server admin login: instructor
 Password: Pa$$w0rd
 Confirm password: Pa$$w0rd
 Location: the closest Azure region (to your location)
 Create V12 server (Latest update): Yes
 Allow azure services to access server: Enabled
o Select source: Blank database
o Resource group: DemoRG
o Pin to dashboard: Enabled

Configure server firewall settings

1. From the Azure portal, navigate to the Firewall settings blade of demodb database.
2. On the Firewall settings blade, identify the public IP address corresponding to your lab virtual
machine.
3. On the Firewall settings blade, create a new rule with the following settings:
o RULE NAME: AllowLabVM
o START IP: XXX.XXX.0.0
o END IP: XXX.XXX.255.255
XXX.XXX represents the first two octets of the client IP address.
Note: The range of IP addresses has been extended to allow for your current location using
a pool of public IP addresses to provide connectivity to the Internet. This allows you to connect
to the SQL Database even if your public IP address changes.
Connect to the Azure SQL Database by using SQL Server Management Studio
1. Start SQL Server 2014 Management Studio, and then connect to the SQL Database server that you
created in this demonstration, by using the following settings:
o Server type: Database Engine
o Server name: server_name.database.windows.net
o Authentication: SQL Server Authentication
o Sign in: Instructor
2. In SQL Server Management Studio, in Object Explorer, verify that the demodb database is listed.
3. Create a new table in the demodb database by running the following Transact SQL code:
CREATE TABLE dbo.demotable

(
id integer identity primary key,
dataval nvarchar(50)
)
4. Add rows to the newly created table by running the following Transact SQL code:
INSERT INTO dbo.demotable

VALUES (newid());
GO 100
5. Script dbo.demotable into the new Query Editor window, and then execute the resulting Transact
SQL code.
6. View the query results, and then verify that a table of id and dataval values is returned.
7. Keep SQL Server Management Studio and Internet Explorer open for the next demonstration.
Configure a client connection string to Azure SQL Database

1. In the D:\Demofiles\Mod07 folder, double-click CompileClientApp.cmd. This compiles a client
application for the demodb database that you created previously.
2. Double-click the newly compiled executable DemoClientApp.exe in the Mod07 folder to run it, wait
for a few seconds, and then note that the application displays an error indicating that it cannot open
a database connection. Press Enter to quit the application.
3. Open DemoClientApp.exe.config in the Mod07 folder by using Visual Studio 2015, and then note
the value of the connectionString attribute for the demoConnectionString setting. You must
modify this to reference the demodb database in your Azure SQL Database server.
4. In the Azure portal, in the Internet Explorer window, navigate to the Database connection strings
blade of the demodb Azure SQL Database.
5. Copy the ADO.NET database connection string to the Clipboard.
6. In Visual Studio, replace the existing connection string with the one that you copied from the Azure
portal, and then in the copied connection string, set the Password parameter with Pa$$w0rd. The
new connectionString value should look similar to the following where server_name represents the
unique name you assigned to the logical SQL server:
Server=tcp:server_name.database.windows.net,
1433;Database=demodb; User ID=Instructor@server_name;
Password=Pa$$w0rd;Encrypt=True;
TrustServerCertificate=False;Connection Timeout=30;
7. Save DemoClientApp.config, and then close Visual Studio.

8. In the Mod07 folder, double-click DemoClientApp.exe to run it, and then note that it now connects
successfully to the database and displays the data values from the dbo.demotable table. Press Enter
to quit the application.

Question
You are planning on creating a new Azure SQL Database on an existing SQL Server by
using Azure portal. What settings can you configure for the new database? Select all
that apply.
Pricing tier
Collation
Resource group
Sign in name and password
Firewall rule for allowing Azure services to access the database

Lesson 3
Managing Azure SQL Database security
Azure SQL Database provides a highly secure platform for hosting relational databases. The principles of
security for Azure SQL Database are for the most part familiar to administrators of SQL Server-based
databases; however, there are some differences between the two security models. In this lesson, you will
learn about the security model in Azure SQL Database, including management of firewall rules, logins,
users, roles, and permissions.
Lesson Objectives
• Describe the key features of Azure SQL Database security.
• Explain how to configure firewall rules.
• Manage logins and users.

• Manage roles and permissions.
• Use SQL Server Management Studio to configure SQL Database security.
Overview of Azure SQL Database security

Azure SQL Database has a hierarchical security
architecture similar to that of SQL Server.
However, the cloud-based nature of Azure
introduces some additional considerations that
you must address when planning and
implementing security.
Server-level security features

At the server level, access to SQL Database is
restricted based on the identity of the user
requesting the connection, and the IP address
of the computer or device from which the
connection is requested.
Server firewall rules

To restrict access from specific devices or networks, SQL Database uses a firewall, which by default allows
connections originating from Azure (these connections are controlled by the firewall rule that is
referencing the IP address of 0.0.0.0). When you create a server, you can optionally disable this
configuration. However, this will effectively prevent access from your applications running in Azure to
any database hosted on this server. To access the databases hosted on the server from systems outside
of Azure, you need to create explicitly one or more firewall rules that include the public IP addresses
assigned to these systems. The Azure portal identifies and displays the IP address of the client device
accessing the portal, which simplifies creating the corresponding rule.
Logins
In a similar way to SQL Server, Azure SQL Database uses logins at the server level to authenticate user
requests. SQL Database does not support Windows-integrated authentication. Traditionally, you had to
rely on SQL Server authentication. Starting with Azure SQL Database V12, you can also use Azure AD
Authentication. Logins are defined in the master database.
Master database roles

Azure SQL Database provides two database roles in the master database. You can assign users to the
database roles in order to grant them server-level permissions. The database roles are:
• loginmanager. This role has permission to create and manage logins.
• dbmanager. This role has permission to create and manage databases.
Note that this architecture is different from that of a computer running SQL Server. A SQL Database server
is a logical entity that contains only databases, including the master database. To assign server-level
management privileges to a login, you must create a user for that login in the master database, and then
add the user (not the login) to the role.
Database-level security features

At the database level, SQL Database provides an extra layer of firewall protection, in addition to the same
security principals as SQL Server.
Database firewall rules

In addition to restricting access to the SQL Database server based on client IP address, you can define
additional firewall rules for individual databases. This enables you to host multiple databases on the same
server while restricting access to each database, based on different ranges of IP address.
Users
Just as with a SQL Server instance, SQL Database requires that logins are mapped to a user in each
database to which they require access. The system administrator login you create when first provisioning
the server is automatically mapped to the dbo user in all databases.
Database roles
SQL Database provides the same database roles that you would find in a database in a SQL Server 2014
instance. They are:
• db_accessadmin. This role can create and manage database users.

• db_backupoperator. This role can back up the database.
• db_datareader. This role can read all data from all user tables in the database.
• db_datawriter. This role can write data in all user tables in the database.
• db_ddladmin. This role can create and manage objects in the database.
• db_denydatareader. This role cannot read data from any table in the database.
• db_denydatawriter. This role cannot write data in any table in the database.
• db_owner. This role can perform all configuration and management tasks in the database.
• db_securityadmin. This role can manage role membership and permissions.

Schema and object level security features

At the schema and object level, SQL Database uses the same permissions-based authorization model as
SQL Server. You can use GRANT, REVOKE, and DENY statements to assign permissions to database
objects for users and roles in the database.
Azure SQL Database V12 security enhancements

Azure SQL Database V12 (equivalent from the versioning perspective to SQL Server 2016) offers a number
of significant security enhancements, including:
• Row-level security. This feature allows you to control access to individual rows in database tables
based on the characteristics of a user or application accessing the database. For example, a user
might be permitted to view only rows where the content of a particular column matches that user’s
name.
• Dynamic Data Masking. This feature complements row-level security by restricting visibility of
individual data items (such as personally identifiable information) to privileged users only.
• Transparent Data Encryption. This feature protects the content of the database at rest by performing
encryption and decryption in real time, as data is being written to and read from the disk. Effectively,
it prevents unauthorized access to data in the unlikely scenario in which someone is able to obtain
copies of the database files.
• Contained databases. This functionality makes it possible to control authentication by creating
database users only, without the need to create logins in the master database. In the case of Azure
SQL Database V12, you can use for this purpose Azure Active Directory identities.
• Always Encrypted. This feature implements encryption at the client application level, ensuring that
sensitive data never reaches the Azure SQL Database in the unencrypted form.
Additional Reading: For more information regarding security enhancements in Azure SQL
Database V12, refer to What's new in SQL Database V12: http://aka.ms/Kzrvvx.
Managing firewall rules

Firewall rules restrict access to SQL Database
server and database based on the IP address of
the client computer or device initiating the
connection.
Managing server firewall rules

You can manage firewall rules for a SQL Database
server directly from its Firewall settings blade in
the Azure portal. There are three options that
allow you to grant access to the server from
specific IP address ranges:
• Allow access to Azure services. Enabling this

option is the equivalent of creating a firewall rule that references the IP address 0.0.0.0.
• Allow the current client IP address. This option provides a convenient way to identify the IP address
that represents the public-facing IP address of the computer or device from which you are currently
accessing the Azure portal. If you are connected directly to the Internet, this will be the IP address
assigned to your computer. More commonly, it is the Internet-facing IP address of the edge device
that connects your local network to the Internet.
• Specify one or more firewall rules. Each rule consists of a unique name, a starting IP address, and an
ending IP address.
You can also manage server firewall rules programmatically by using Azure PowerShell module or
representational state transfer (REST) application programming interface (API) or, once connected to the
SQL Server, by invoking the sp_set_firewall_rule and sp_delete_firewall_rule system stored procedures
in the master database. You can view server firewall settings by querying the sys.firewall_rules system
view in the master database.
Managing database firewall rules

To manage database firewall rules, you can use the sp_set_database_firewall_rule and
sp_delete_database_firewall_rule system stored procedures in the database to which these firewall
rules apply. You can use Azure REST API or Windows PowerShell to implement the same functionality.
To view database firewall rules in a specific database, you can query its sys.database_firewall_rules
system view.
Note: Firewalls can make it difficult to troubleshoot connectivity issues, so you should
always start by identifying IP addresses that have been allowed to access to Azure SQL Database.
Remember that firewall rules can take several minutes to become active. If the correct ranges
have been granted access, check your local firewall configuration and IP address. Your local
firewall must permit outbound TCP connections to port 1433. If your client device uses
Dynamic Host Configuration Protocol (DHCP), you should verify that the current IP address is
included in one of the ranges defined in Azure SQL Database. Finally, keep in mind that in
scenarios involving network address translation (NAT), the client IP address that Azure SQL
Database detects will most likely differ from the one shown in your local IP settings.
Managing logins and users

You can manage logins and users in Azure SQL
Database by running Transact-SQL statements
and using system stored procedures. To manage
logins, you must establish a session that is
connected to the master database; to manage
users, you must connect to the database where
the user is to be defined. Remember that you
cannot change database context in a session. To
create a login and a database user, you must first
connect to the master database to create the
login, and then establish another session in the
appropriate database to create the associated
user.
Managing logins
To create a login, connect to the master database and use the CREATE LOGIN Transact-SQL statement,
specifying a name and password for the login.
The following code sample shows how to create a login named MyLogin with the password Pa$$w0rd:
CREATE LOGIN MyLogin

WITH PASSWORD = ‘Pa$$w0rd’;
After you have created a login, you can change the password by using the ALTER LOGIN Transact-SQL
statement and delete the login by using the DROP LOGIN Transact-SQL statement.
When connecting to Azure SQL Database, client applications that use SQL Server authentication must
specify the login name and password in the connection string used to establish the connection.
When specifying the login name, you should use the syntax login_name@server_name. For example, if
your SQL database server is named abcd1234, and your login is named MyLogin, your connection string
should specify the login as MyLogin@abcd1234.
Managing users
Users are the mechanism by which logins are granted access to databases. To create a user, connect to the
database to which you want to grant access and use the CREATE USER Transact-SQL statement,
specifying the associated login.
The following code sample shows how to create a user named MyUser for the MyLogin login:
CREATE USER MyUser

FROM LOGIN MyLogin;
After you have created a user, you can delete it by using the DROP USER Transact-SQL statement.
Managing role membership and permissions

Azure SQL Database uses roles to simplify
permissions management for groups of users.
Additionally, you can use GRANT, REVOKE, and
DENY statements to explicitly assign permissions
or to override permissions inherited by an
individual user from membership in a role.
Managing role membership

Server level permissions in SQL Database are
primarily intended for the management of
databases and logins. To perform any server-level
tasks, a login must have a user account in the
master database, and this user must be a member
of a role that has permission to carry out the task. The loginmanager role has permission to create and
manage logins, and the dbmanager role has permission to create and manage databases.
To add a user in the master database to a role with server-level permissions, use the sp_addrolemember
system stored procedure as shown in the following example:
EXEC sp_addrolemember 'dbmanager', 'MyUser';

At the database level, administrative permissions are encapsulated in database roles, defined in each
database, to which you can add users.
To add a user to a database role, use the sp_addrolemember system stored procedure in the appropriate
database as shown in the following example:
EXEC sp_addrolemember 'db_datareader', 'MyUser';
Note: The ALTER SERVER ROLE and ALTER ROLE statements are not supported in Azure
SQL Database. You must use the sp_addrolemember system stored procedure to add users to
server roles (in the master database only) and database roles (in all databases).
Managing permissions
You can use GRANT, REVOKE, and DENY statements to assign explicit permissions that enable users to
perform specific tasks or access particular database objects. In general, the simplest approach to designing
database security is to use role membership to define the base set of permissions that are required, and
only use explicit permissions to extend or override permissions inherited from role membership.
The following example shows how to deny the Select permission on a specific table, even if the user has
been granted permission through membership of the db_datareader role:
DENY SELECT ON dbo.MyTable TO MyUser;
Demonstration: Configuring security

In this demonstration, you will see how to manage logins, users, roles, and permissions.
Demonstration Steps
1. Ensure that you have completed the previous demonstration in this module.
2. In SQL Server Management Studio, view the server logins and verify that Instructor login is listed.
3. Create a new login by running the following Transact SQL script:
CREATE LOGIN DemoLogin

WITH PASSWORD = 'Pa$$w0rd';
GO
4. In SQL Server Management Studio, view the server logins and verify that DemoLogin login is listed.
5. Create a new user DemoUser in the demodb database and assign it to the db_datareader and
db_datawriter roles by running the following Transact SQL script:
CREATE USER DemoUser

FOR LOGIN DemoLogin
WITH DEFAULT_SCHEMA = dbo;
GO
EXEC sp_addrolemember 'db_datareader', 'DemoUser';
GO
EXEC sp_addrolemember 'db_datawriter', 'DemoUser';
GO
6. In SQL Server Management Studio, view the users of the demodb database and verify that the
DemoUser has been created.
7. Deny permissions to update and delete the demotable table in the demodb database for the
DemoUser by running the following Transact SQL script:
DENY update, delete ON dbo.demotable TO DemoUser;
8. Open a new Query Editor tab, but this time connect to the master database of the same logical SQL
server by using the DemoLogin login with the Pa$$w0rd password.
9. Point out that the connection fails because DemoLogin does not have a user account in the master
database.
10. Open a new Query Editor tab, but this time connect to the demodb database of the same logical
SQL server by using the DemoLogin login with the Pa$$w0rd password.
11. Point out that the connection succeeds because the DemoLogin login has a user account in the
demodb database.
12. From the Query Editor tab opened in the previous step, run the following Transact SQL query to view
the content of the demotable table in the demodb database:
SELECT * FROM dbo.demotable
13. Note that the query succeeds because the user has permission to read the table through membership
of the db_datareader role.
14. In the same Query Editor window, enter and run the following Transact-SQL code:
INSERT INTO dbo.demotable

VALUES
(newid());
15. Note that the query succeeds because the user has permission to modify the table through
membership of the db_datawriter role.
UPDATE dbo.demotable
SET dataval =newid()
WHERE id = 1
17. Note that an error is returned. Although the user has permission to modify the table through
membership of the db_datawriter role, permission to update the table has been explicitly denied to
the user.
DELETE dbo.demotable
WHERE id = 1
19. Note that an error is returned. Although the user has permission to modify the table through
membership of the db_datawriter role, permission to delete data from the table has been explicitly
denied to the user.
20. Close SQL Server Management Studio without saving any files, but keep Internet Explorer open for
the next demonstration.

Question
What methods or tools could you use to implement database firewall rules for an
Azure SQL Database? Select all that apply.
Azure PowerShell
SQL Server Management Studio
SQLCMD
Azure portal
SQL Server Configuration Manager

Lesson 4
Monitoring Azure SQL Database
While Microsoft Azure SQL Database requires less ongoing maintenance than a SQL Server instance, you
should still monitor your databases to help determine usage requirements, plan upgrades, and
troubleshoot performance and security issues.
Lesson Objectives
• Describe how SQL Database monitoring metrics and alerts enable administrators to profile the
performance of each server and database.
• Use dynamic management views to monitor SQL Database.
• Configure auditing for SQL Database.
• Monitor SQL Database metrics and configure alerts.
Metrics and alerts

You can monitor key metrics for SQL Database
directly in the Azure portal.
You can view trends for SQL Database metrics,

including:
• Successful and failed connections.
• Storage utilization.
These metrics are shown as charts in the Azure

portal.
You can configure alerts for each metric, which

trigger an automated email notification when a
metric exceeds a specified threshold value over a specified period of time.
Dynamic management views

Azure SQL Database supports a subset of the
dynamic management views and dynamic
management functions provided in Microsoft SQL
Server. These objects allow database
administrators to query system metadata to
retrieve details of:
• Current activity. For example, a list of

transactions that are currently active in the
database.
• Historic activity. For example, a list of previously executed queries ordered by execution time.
The ability to retrieve details of current activity is particularly useful for troubleshooting concurrency
issues, where data access tasks from one client application are blocking activity for another.
Additional Reading: For details of dynamic management views supported in Azure SQL
Database, refer to Monitoring Azure SQL Database using dynamic management views:
http://aka.ms/Hqwc0x.
Database auditing
Many organizations require data access to be
audited for compliance reasons, to ensure non-
repudiation of data access, or to troubleshoot
database activity. Azure SQL Database supports
auditing for SQL Databases based on Basic,
Standard, and Premium editions. Azure SQL
Database also provides a user interface in the
Azure portal and a Microsoft Excel workbook
template that you can use to view and analyze
audit events. The audit event records are stored in
a table in an Azure Storage account.
Enabling auditing
Before you can enable SQL Database auditing, you must create an Azure Storage account in which the
audit events will be stored. Then, you can enable auditing for any Basic, Standard, or Premium database in
the Azure portal and specify the types of events that should be audited.
Using secure connection strings

To audit events, client applications must connect to a SQL Database by targeting
server_name.database.secure.windows.net instead of the default server_name.database.windows.net.
Traditionally, you had to make modifications to the application connection strings. Since tabular data
stream (TDS) client version 7.4, this is no longer necessary because incoming connections are
automatically redirected to the proper target. Note that for legacy clients, utilizing older versions of TDS,
.NET, or Open Database Connectivity (ODBC), you will still have to modify the connection string used by
applications that perform activities you want to audit.
Viewing audit events

You can view a summary of audit events for a database in the Azure portal. Additionally, you can export
the audit events as an Excel workbook, which enables you to analyze the events using the tools in Excel.
Demonstration: Monitoring Azure SQL Database

• View SQL Database metrics.
• Configure SQL Database auditing.
Demonstration Steps
View SQL Database metrics

1. Ensure that you have completed the previous demonstrations in this module.
2. From the Azure portal, in Internet Explorer window, navigate to the demodb SQL Database blade.
3. On the demodb blade, note the charts displayed in the Monitoring section, which show resource
utilization in terms of DTU percentage.
4. Add Total database size to the Resource utilization chart.
5. Display the Metric blade for the Resource utilization chart.
6. On the Metric blade, add an alert with the following settings:
o Resource: leave the default setting in place
o Name: demodb storage alert
o Description: storage alert for demodb database

o Metric: total database size
o Condition: greater than
o Threshold: 1048576
o Period: over the last 5 minutes
o Email owners, contributors, and readers: selected
o Additional administrator email(s): any email address

o Webhook: leave blank
7. Save the alert, which will notify administrators if the database storage size exceeds 1 megabyte (MB)
within a five-minute period. Note that the values you chose are for demonstration purposes only.
Configure SQL Database auditing

1. In Internet Explorer, in the Azure portal, create a new Classic storage account.
2. Set the following storage account settings:

o Name: a valid, unique name for a new storage account
o Replication: Locally-redundant storage (LRS)
o Subscription: your Azure subscription

o Resource Group: DemoRG
o Location: the same location where you created your Azure SQL Database server
o Pin to dashboard: selected
3. Wait for the new storage account to become available.
4. In the Azure portal, navigate to the demodb blade.
5. From the Settings blade of demodb, navigate to the Auditing & Threat detection blade.
6. On the Auditing & Threat detection blade, clear the Inherit settings from server check box and
apply the following settings:
o Auditing: ON
o Auditing Type: Table
o Storage Details: leave the default (pointing to the storage account you created earlier)
o Audited Events: All
o Threat detection (preview): OFF
7. Click Explore and point out that this is where you would see audit records.
8. Open DemoClientApp.exe.config in the D:\Demofiles\Mod07 folder in Visual Studio.
9. In Visual Studio, modify the value of the connection string attribute by adding the word secure in
front of .windows.net (make sure that you keep existing punctuation). The new value of
connectionString value should look similar to this (on a single line):
Server=tcp:server_name.database.
secure.windows.net,1433;
Database=demodb; User ID=Instructor@server_name;
TrustServerCertificate=False;
Connection Timeout=30;
10. Save DemoClientApp.config and close Visual Studio.
11. In the D:\Demofiles\Mod07 folder, double-click DemoClientApp.exe to run it, and verify that it
connects successfully to the database and displays the data values from the dbo.demotable table.
Press Enter to end the application.
12. Switch back to the Azure portal in the Internet Explorer window and refresh the view of audit records
in the Audit records (preview) blade.
13. Note that the Auditing blade contains additional Login and DataAccess events.
14. Keep Internet Explorer open for the next demonstration.


Question
You have an application that uses TDS 7.3 to access an Azure SQL Database. You need
to ensure that all application data–access attempts are recorded by leveraging the
Azure SQL Database functionality. What three actions should you perform to
accomplish this?
Modify the database connection string that the application uses to connect to
Azure SQL Database
Configure Azure SQL Database metrics
Configure Azure SQL Database alerts
Create an Azure Storage account
Enable Azure SQL Database auditing

Lesson 5
Managing Azure SQL Database business continuity
One of the primary responsibilities of database administrators and infrastructure managers is to ensure
business continuity in the event of a failure. This usually involves ensuring that you back up data on a
regular basis and retain them so that they can be used to restore applications in the event of failure.
Additionally, some business-critical applications might require a high-availability solution in which a
redundant copy of the database is maintained in a standby state.
This lesson discusses ways to implement database recovery and high availability for Azure SQL Database.
Lesson Objectives
• Copy and export an Azure SQL Database.
• Perform a restore of an Azure SQL Database.

• Configure and manage geo-replication of Azure SQL Database.
• Manage data recovery and high availability.
Database copy and export

In Azure SQL Database, you cannot directly use
the database and transaction log backup
capabilities of SQL Server. Historically, this was
remediated by periodically exporting a copy of
each database that you want to protect, and
storing the copy in a .bacpac file in a storage
account. In the event of a SQL database or server
failure, you could then create a new SQL database
server, if necessary, and import the copy of the
database from the exported file.
This approach provides a simple data

recoverability solution that is analogous to a full
database backup strategy in a computer running SQL Server. Though, it does introduce operational
overhead and incurs the extra cost of storage occupied by backup copies. These shortcomings are
eliminated by the capabilities built-into the Azure SQL Database server, which we will cover in the next
topic.
There are many factors that you should you consider when deciding whether to use database copy and
export or rely on point-in-time restore for backups of Azure SQL Database. Some of these factors include:
• Operational overhead
• Transactionally consistent backup
• Extra cost
• The ability to perform on-premises restore

Point-in-time restore is a functionality built into Azure SQL Database, so it does not introduce any
operational overhead. However, copy and export involves a manual process that customers must
implement themselves.
Point-in-time restore offers transactionally consistent backups by performing an incremental backup

every five minutes. You should not perform an export on the live data, it requires creating a database
copy first.
There is no extra cost associated with the point-in-time restore. With database copy and export, you will
be charged for an additional database instance and for the storage hosting the exported data.
Restore to on-premises is available only with the export and copy.
Self-service restore
When you create a database in a Microsoft
Azure SQL Database server, Microsoft Azure
automatically backs up the database periodically
to a geo-replicated storage account, allowing you
to restore the database to an earlier state.
Additionally, if the database is accidentally
deleted, you can restore it from the most recent
automatic backup. Each database is subject to a
full weekly backup, followed by daily differential
backups, and further by supplemented
incremental backups that take place every five
minutes. The retention of restore points depends
on the edition of Azure SQL Database:
• Basic. You can restore the Basic edition databases to the most recent daily restore point within a 24-
hour period.
• Standard. You can restore the Standard edition databases to a specific point in time within a seven-
day period.
• Premium. You can restore the Premium database to a specific point in time within a 35-day period.
You can restore databases by using the Azure portal, or by using Windows PowerShell. You can restore an
existing database to revert accidental or invalid changes to data. When you restore an existing database,
Azure creates a new database of the same service tier with a name that reflects the date and time to
which the database has been recovered. After you have verified that the recovered database contains the
required data, you can delete the original database and then use ALTER DATABASE statement to rename
the restored database to match the original name.
When you delete an entire database, it remains listed in the portal until its retention period has expired.
You can restore deleted databases to the most recent recovery point.
Geo-replication
Although both copy-based and automatic
backups 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 an
application that relies on a SQL database, you can
implement geo-replication. In geo-replication,
one or more redundant copies of the database are
maintained and updated on a continuous basis in
a remote datacenter. In the event of a failure, you
can then failover to the secondary database and
modify application connection strings to use the copy, which is typically faster than restoring a large
database from a backup.
Standard pricing tier databases support a single readable or non-readable secondary copy. Premium
pricing tier offers up to four readable, secondary databases. The read-only mode allows you to offload
such tasks reporting or near real-time data analysis to secondary databases and reduce utilization of the
primary database.
Demonstration: Managing data recovery and high availability

• Restore a database.
• Configure geo-replication.
Demonstration Steps
Restore a database
1. Ensure that you have completed the previous demonstrations in this module.
2. In Internet Explorer, in the Azure portal, navigate to the demodb SQL Database.
3. On the demodb blade, activate its Restore blade to verify whether a restore point is available. If not,
wait until it is available.
4. After you verified that the restore point has been created, delete the demodb SQL Database.
5. After the database has been deleted, in the D:\Demofiles\Mod07 folder, double-click
DemoClientApp.exe to run it, note that an error is displayed, and then press Enter to end the
application.
6. In the Azure portal, browse to the SQL server where demodb database was created.
7. On the SQL server blade, display the list of its Deleted databases.
8. On the Deleted databases blade, initiate the restore of the demodb database.
9. Wait for the restore operation to complete by monitoring Notifications area in the portal or on the
Audit Logs blade (this can take several minutes).
10. In the D:\Demofiles\Mod07 folder, double-click DemoClientApp.exe to run it, verify that the
application now retrieves the data values from the restored database, and then press Enter to end the
application.
Configure geo-replication
1. In Internet Explorer, in the Azure portal, navigate to the Geo-Replication blade of demodb SQL
Database.
2. On the Geo-Replication blade, create an offline secondary replica with the following settings:
o Region: Accept the recommended region
o Secondary type: Readable
o Target name: any valid unique SQL server name
o Server admin login: Instructor
o Confirm password: Pa$$w0rd

o Create V12 server (latest update): Yes
o Allow azure services to access server: Enabled
3. Note that you can only select a non-readable secondary. To enable the readable secondary type, you
need to upgrade the database to Premium edition (demodb is using the Standard pricing tier).
4. View the graphical representation of the geo-replication on the Geo-Replication blade.

Reset-Azure
subscription.

groups.
directory.
Question: What factors should you consider when deciding whether to use database copy
and export or rely on point-in-time restore for backups of Azure SQL Database?
Lab: Planning and implementing Azure SQL Database

Scenario
Managers at A. Datum are planning to migrate some of the company’s application databases to the cloud.
To achieve this goal, you plan to use Microsoft Azure SQL Database. You have been asked to test SQL
Database by creating a new database of A. Datum servers and by migrating sample data from the A.
Datum customer relationship management system. Managers have asked you to investigate how SQL
Database will support an existing custom application used with A. Datum, as well as disaster recovery
features.
Objectives
• Provision Azure SQL Database.
• Migrate a SQL Server database to Azure SQL Database.
• Restore a deleted database.
Lab Setup

User name: Student
Password: Pa$$w0rd
Before starting this lab, ensure that you have performed the “Preparing the Environment” demonstration
tasks at the beginning of the first lesson in this module, and that the setup script has completed.
Exercise 1: Creating, securing, and monitoring an Azure SQL Database

Scenario
The operations team at A. Datum currently uses a Microsoft SQL Server database to store inventory of
company’s servers. You want to investigate the option of using Azure SQL Database to host this database.
The operations team is interested in monitoring the performance of this database in Azure.
Note: The Microsoft Azure portal is continually improved, and the user interface might
have been updated since this lab was written. Your instructor will make you aware of any
differences between the steps described in the lab and the current Azure portal user interface.
1. Create an Azure SQL Database.
2. Configure server firewall rules.
3. Use SQL Server Management Studio.
4. View database metrics.

 Task 1: Create an Azure SQL Database

1. Sign in to the 20533C-MIA-CL1 lab virtual machine as Student with the password Pa$$w0rd.
2. Launch Internet Explorer and sign in to the Azure portal by using the Microsoft account that is the
Subscription Administrator or Co-Administrator of your Azure subscription.
3. From the Azure portal, create a new SQL database with the following parameters:
o Name: operations
o SQL server
 Server name: any valid unique name
 Server admin login: Student
 Password: Pa$$w0rd
 Confirm password: Pa$$w0rd
 Location: the closest Azure region (to your location)
 Create V12 server (Latest update): Yes
 Allow azure services to access server: Enabled
o Select source: Blank database
o Resource group: OpsRG
4. After the database is created, the portal will automatically display its Settings blade.
 Task 2: Configure server firewall rules

1. From the Azure portal, navigate to the Firewall settings blade of operations database.
2. On the Firewall settings blade, identify the public IP address corresponding to your lab virtual
machine.
3. On the Firewall settings blade, create a new rule with the following settings:
where XXX.XXX represents the first two octets of the client IP address.
 Task 3: Use SQL Server Management Studio

1. Use SQL Server Management Studio to connect to the Azure SQL server with the following settings:
o Login: Student
2. In SQL Server Management Studio, in Object Explorer, verify that the operations database is listed.
3. From SQL Server Management Studio, execute the Transact SQL script stored in the Operations.sql
file in the D:\Labfiles\Lab07\Starter folder.
4. From SQL Server Management Studio, run the following query against the operations database:
SELECT * FROM dbo.serverlist;
5. View the query results and verify that a list of three servers and their IP addresses is returned.
6. Keep SQL Server Management Studio and Internet Explorer open.
 Task 4: View database metrics

1. From the Azure portal, in the Internet Explorer window, navigate to the operations SQL Database
blade.
2. On the operations blade, note the charts displayed in the Monitoring section, which show resource
3. Add Total database size to the Resource utilization chart.
4. Display the Metric blade for the Resource utilization chart.

5. On the Metric blade, add an alert with the following settings:
o Name: operations storage alert
o Description: storage alert for operations database

o Threshold: 1024
6. Keep Internet Explorer open for the next exercise.
Results: After completing this exercise, you should have created an Azure SQL Database named
operations on a new server with a name of your choosing. You should also have used SQL Server
Management Studio to create a table named dbo.serverlist and created an alert to help you monitor
database storage.
Exercise 2: Migrating a Microsoft SQL Server Database to Azure SQL

Database
Scenario
The sales team at A. Datum uses a customer relationship management system application to track
customer invoices. The application currently stores customer data in an on-premises Microsoft SQL Server
database. You want to demonstrate that Azure can support this customer relationship management
system application by migrating the database for this application to Azure SQL Database, and then
reconfiguring the application to use the new, cloud-based database.

1. Deploy a database to Azure.
2. Configure SQL Database security.
3. Configure an application connection string.
 Task 1: Deploy a database to Azure

1. In SQL Server Management Studio, connect to the SQL Server instance running on MIA-CL1 by using
Windows authentication.
2. Verify that the sales database is listed in the Databases folder for the MIA-CL1 server.
3. Right-click the sales database, point to Tasks, and click Deploy Database to Windows Azure SQL
Database. Then use the wizard to deploy the sales database from MIA-CL1 to your Microsoft Azure
SQL Database server. Ensure that the Service Objective is set to S2.
 Task 2: Configure SQL Database security

1. In SQL Server Management Studio, in Object Explorer, under your Azure SQL Database server, expand
Security, expand Logins, and verify that only the Student login is listed.
2. Create a new login named SalesApp with the password Pa$$w0rd by executing the following
Transact-SQL code in the master database:
CREATE LOGIN SalesApp

WITH PASSWORD = 'Pa$$w0rd'
GO
3. In Object Explorer, in the Databases folder for your Azure SQL Database server, expand the sales
database, expand Security, and expand Users to view the users that are defined in the sales
database.
4. Create a user named SalesApp for the SalesApp login. The user should have a default schema of
dbo, and should be added to the db_owner database role. You can create the user by executing the
following Transact-SQL code in the sales database:
CREATE USER SalesApp

FOR LOGIN SalesApp
WITH DEFAULT_SCHEMA = dbo
GO
EXEC sp_addrolemember 'db_owner', 'SalesApp'
GO
5. Keep SQL Server Management Studio open for the next exercise.
 Task 3: Configure an application connection string

1. Start Visual Studio and open the SalesApp.sln solution in the D:\Labfiles\Lab07\Starter folder.
Then, open its Web.config file and note that the SalesConnectionString setting connects to the
sales database on the localhost server using integrated security (Windows authentication).
2. In Internet Explorer, in the Azure portal, browse to the sales database blade.
3. On the sales database blade, identify the value of the ADO.NET database connection string and
copy it to the Clipboard.
4. In Visual Studio, replace the existing connection string with the one you copied from the Azure portal.
Then in the copied connection string, set the value of the User ID parameter to
SalesApp@server_name (where server_name is the name of your Azure SQL Database server). Next,
set the value of the Password parameter to Pa$$w0rd. The new connectionString value should look
similar to this:
1433;Database=sales; User ID=SalesApp@server_name;
5. Save Web.config. Then on the Debug menu, click Start Debugging.
6. When Internet Explorer opens, verify that the sales application shows invoice history data for the
selected customer. The data is retrieved from the sales database you migrated to Microsoft Azure SQL
Database.
7. Close the Internet Explorer window that contains the sales application, ensure that the Visual Studio
debugger is stopped, and then close Visual Studio, saving changes if prompted.
Results: After completing this exercise, you should have deployed the sales SQL Server database on the
local SQL Server instance to your Azure SQL Database server, and configured the SalesApp web
application to use a connection string for the new Azure SQL Database.
Exercise 3: Restoring a database

Scenario
The operations database you created is considered a mission-critical source of data for IT employees at
A. Datum. Before business decision makers can commit to using Azure to host this database, you must
ensure that the database can be recovered in the event of accidental deletion.
1. Delete a database.
2. Restore a deleted database.
4. To prepare for the next module.

 Task 1: Delete a database

1. In Internet Explorer, in the Azure portal, from the operations SQL Database blade, verify that there is
at least one restore point. If not, wait until that is the case.
2. After you verified that there is a restore point, delete the operations SQL Database.
3. In SQL Server Management Studio, refresh the Databases folder for your Azure SQL Database server
to verify that the operations database is no longer on the server.
 Task 2: Restore a deleted database

1. In the Azure portal, browse to the SQL server where operations database was created.
2. From the SQL server blade, display the list of its deleted databases.
3. From the Deleted databases blade, initiate the restore of operations database.
Note: If the initial restore attempt fails, try again.
5. In SQL Server Management Studio, in Object Explorer, refresh the list of databases to verify that the
operations database has been restored.
6. In SQL Server Management Studio, run the following query against the operations database:
SELECT * FROM dbo.serverlist

Reset-Azure

lab.
Important: The script might not be able to get exclusive access to a storage account to delete it (if this
occurs, you will see an error). If you find objects remaining after the reset script is complete, you can re-
run the Reset-Azure script, or use the Azure portal and Azure classic portal to manually delete all the
objects in your Azure subscription—with the exception of the default directory.
Results: After completing this exercise, you should have deleted and restored the operations database.
 Task 4: To prepare for the next module

Leave the virtual machines running for the next module.
Question: If the SalesApp web application was deployed to a server with a fixed public IP
address, how could you enable it to access the sales Azure SQL Database without allowing it
to access any other Azure SQL Database on the same server running SQL?

Review Question
Question: What are the considerations for choosing between on-premises server running
SQL, SQL Server in an Azure IaaS virtual machine running SQL, and Azure SQL Database?

Your connection from SQL Server

Management Studio running on an on-
premises computer to an Azure SQL
Database server fails with the connectivity
error.
8-1
Module 8
Implementing PaaS cloud services
Contents:
Module Overview 8-1
Lesson 1: Planning and deploying PaaS cloud services 8-2
Lesson 2: Managing and maintaining cloud services 8-11
Lab: Implementing PaaS cloud services 8-20
Module Overview
Platform as a Service (PaaS) cloud services constitute another hosting model you can use to run web
applications and web services in Microsoft Azure. These cloud services use a modular architecture that
allows you to scale your application to very large sizes while minimizing costs. In this module, you will see
how to create, configure, manage, and monitor cloud services.
Objectives
• Plan and deploy Azure Cloud Services in Azure.
• Explain how to manage and maintain Azure Cloud Services.

8-2 Implementing PaaS cloud services
Lesson 1
Planning and deploying PaaS cloud services
Azure provides two main categories of hosting options for applications: infrastructure as a service (IaaS)
and PaaS. So far, this course has covered IaaS virtual machines and PaaS app services. In this lesson, you
will see how PaaS cloud services differ from Azure App Services and Azure Virtual Machines and how PaaS
cloud services allow you 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 how PaaS cloud services integrate with other Azure services to support applications.
• Explain how to create and deploy Azure Cloud Services.
• Describe how to manage Azure Cloud Services deployment environments.

• Explain how to update Azure Cloud Services.
Demonstration: Preparing the Microsoft Azure environment

Perform the tasks in this demonstration to prepare the lab environment. The Microsoft Azure services you
will use in the lab will be described in this module while the environment is being configured.
Important: The scripts used in this course might delete objects that you have in your
subscription. Therefore, you should complete this course by using a new Azure subscription. You
should have received sign-up details and instructions for creating an Azure learning pass for this
reason. Alternatively, you can create a new Azure trial subscription. In both cases, use a new
Microsoft account that has not been associated with any other Azure subscription. This will
eliminate the possibility of confusion when running setup scripts.
The labs in this course use custom Azure PowerShell cmdlets including Setup-Azure to prepare the Azure
environment for a lab, and Reset-Azure to perform clean-up tasks at the end of a lab. Setup-Azure
removes any current Azure subscription and account references from the Azure PowerShell session.
• Sign in to your Microsoft Azure subscription.
• Prepare the Azure environment
Demonstration Steps

1. On the MIA-CL1, on the taskbar, right-click Windows PowerShell, and then click Run as
administrator. In the User Account Control dialog box, click Yes.
Setup-Azure
The script will take a few seconds to configure your Azure environment, which will be ready to use for the
lab at the end of this module.
PaaS cloud services as components of Azure

Azure Virtual Machines is an IaaS execution model
that allows you to install and configure servers
to run both stateful and stateless applications in
the cloud. Azure App Services is a PaaS execution
model that you can use to run stateless
applications and services without maintaining
underlying hardware, operating systems, and
web servers. You have seen these services earlier
in this course. In this module, you will learn about
another hosting model currently available in
Azure, which is referred to as PaaS cloud services.
Note: In Azure, the term cloud service can

refer to either a cloud service that hosts IaaS V1 virtual machines or a cloud service that hosts
web roles and worker roles. In this course, the term IaaS cloud service refers to a service that
contains IaaS V1 virtual machines, and the term PaaS cloud service refers to a service that
contains web and worker roles. This terminology ensures clarity. Considering that the concept of
cloud services no longer applies to IaaS V2, less room for confusion now exists. However, you
might still encounter this term in the context of IaaS V1.
You can use the PaaS cloud services hosting model to host websites or web services. You can build these
web services with a more modular architecture than 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, whereas a worker role typically handles background tasks.
Just like Azure App Services, PaaS cloud services allow you to scale out your applications to help ensure
fault tolerance and provide scalability. However, you have extra flexibility with PaaS cloud services,
because you can scale each role independently of other roles in the same application. Note that despite
this modularity, you can configure virtual machines hosting different roles to directly communicate with
each other within the same cloud service.
PaaS cloud services closely integrate with other Azure PaaS services as well as with IaaS V1 services. For
example, you can deploy a PaaS cloud service into an IaaS V1 virtual network (VNET) to allow direct
communication with other PaaS cloud services or IaaS V1 virtual machines. This also allows PaaS cloud
services to communicate directly with IaaS V2 virtual machines, as long as the IaaS V1 VNET is connected
to an IaaS V2 VNET via a VNET-to-VNET connection.
You can use an IaaS V1 storage account or an Azure SQL Database instance to provide persistent storage
for virtual machines running web and worker roles. This, in turn, allows you to facilitate scenarios that
require preserving the session state, which should not be stored directly within PaaS cloud services
because of their stateless nature. Temporary storage services (such as Azure Storage queues or Azure
Service Bus queues) also provide a means of asynchronous messaging between web and worker roles.
PaaS cloud services can also use Azure services such as Content Delivery Network, Azure Traffic Manager,
and Azure Active Directory, which enhance the capabilities of web applications and services. You
implement these services to interact with PaaS cloud services in a similar way as in IaaS virtual machines
or app services.
Azure PaaS cloud services are not compatible with IaaS V2 services. You cannot, for example, deploy a
PaaS cloud service to an IaaS V2 VNET or use an IaaS V2 storage account to store its session state.
PaaS cloud services overview

Traditionally, you could use three hosting models
for running applications in Azure:
• Azure IaaS virtual machines. This model

involves running applications within
customized Windows and Linux virtual
machines. It offers the highest degree of
control of the operating system, allowing you
to install, customize, and run almost any
application, providing that the resulting
configuration does not rely on network or
storage infrastructure functionality that is not
currently supported in Azure. Such flexibility,
however, comes with management overhead, because you, as the owner of the virtual machines, are
responsible for the maintenance and updates of the operating system, the application, and any of its
software dependencies.
• Azure PaaS app services. This model eliminates the management overhead associated with Azure IaaS
virtual machines. It delivers a fully managed platform designed specifically to optimize the
development, deployment, and running of web and mobile applications. These optimizations, along
with the stateless nature of applications supported by this model, result in superior agility. App
services also considerably simplify the integration and automation of business processes as well as
building, publishing, and consuming cloud APIs. However, the simplicity and ease of use limit your
flexibility to some extent. For example, this affects your ability to use app services to implement
multitier applications, where the compute and web tiers must operate and scale independently.
• Azure PaaS cloud services. This model combines the advantages of IaaS virtual machines and PaaS
app services. It gives you direct access to the virtual machines hosting your applications, but at the
same time, it relies on the platform to handle their maintenance and updates. It is well suited for
supporting multi-tier applications by facilitating distinct roles, with the Web role providing front-end
services and the Worker role handling background tasks. Because the Azure platform must provision
virtual machines automatically for each tier, the entire configuration of the virtual machines must be
defined by using a combination of compiled code and configuration files. Consequently, they are
stateless and should not be used to store any data.
Note: The differences among the hosting models just listed become less distinct as Azure
services evolve. For example, Azure App Services includes a Premium service plan option, called
Azure App Service Environment, intended for multi-tier applications. This is possible because of
its ability to host multiple resource pools, with one of them providing front-end services and up
to three handling background tasks.
Similarly, Azure IaaS V2 virtual machine scale sets, with their elasticity and superior scale-out
capabilities, resemble Azure PaaS services in many aspects.
This traditional arrangement is changing with the advent of microservices, which represent small, self-
contained components of individual applications. In particular, Azure Service Fabric is quickly emerging
as a new PaaS hosting model along with other microservices-based application platforms, such as Docker
Compose or Mesosphere Marathon. For example, Service Fabric is frequently referred to as PaaS 2.0
because of its support for both stateful and stateless services and its improved use of computing
resources. The latter results from the more efficient distribution of application components across multiple
virtual machines.
Containers provide another way to host applications in Azure. They enable running multiple applications
fully isolated from each other on the same Azure virtual machine, further increasing resource utilization.
In addition, containerization based on Docker and Windows Server Containers offers a standardized
approach to application packaging and deployment, best exemplified by Azure Container Service. You
can also use containers in combination with the microservices-based application hosting model. This
allows you to capitalize on the benefits offered by each, including hyperscaling and increased density as
well as isolation and standardized application management.
Roles in a PaaS cloud service

As mentioned earlier, in a PaaS cloud service, developers can divide the expected workload and the
corresponding code into separate roles. Two types of roles exist:
• Web roles. A web role serves as the front end of the cloud service and runs on one or more virtual
machines, with each one hosting a Microsoft Internet Information Services (IIS) web server. For
example, in a website based on Microsoft .NET, the web role contains the webpages that make up
the user interface for the application.
• Worker roles. A worker role typically handles asynchronous background processes. It also commonly
runs on one or more dedicated virtual machines. A web role commonly uses a worker role to
complete resource-intensive, long-running, or continuous tasks.
A PaaS cloud service can include many roles. You can configure each role to have multiple instances. By
creating multiple instances for each role, you can scale out the cloud service and increase its resilience to
failures.
Web roles and worker roles enable flexible and efficient scaling. For example, if an application has one
processor-intensive task, such as video processing, developers can separate that code into a worker role.
When you deploy the cloud service, you can scale the processor-intensive task independently without
having to scale out the entire application, which would unnecessarily increase the overall cost.
Note: Create at least two instances of each role in your PaaS cloud service. This helps
ensure that an instance is available to respond to users if a single failure occurs. You must create
at least two instances of each role to qualify for the 99.95 percent uptime guarantee stipulated in
the Azure service level agreements (SLAs). Instances of the same role run in separate fault
domains and separate upgrade domains.
Because virtual machines hosting role instances are stateless, it is common to configure PaaS cloud
services to use a database to store any content that needs to be preserved. To implement such a database,
you can run Microsoft SQL Server in an Azure virtual machine or deploy a SQL Database instance.
You can create a PaaS cloud service by using a configuration file and an application package containing
compiled code and a cloud service definition file. The next lesson explores the structure of a PaaS cloud
service in more detail.
Creating and deploying PaaS cloud services

Developers create PaaS cloud services by coding
in an Integrated Development Environment (IDE)
such as Microsoft 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. After the
cloud service is complete, you must create a cloud
service in Azure and deploy the completed
service.
Creating a PaaS cloud service

To create a PaaS cloud service in the Azure classic
portal, complete the following steps:
1. In the left pane, click CLOUD SERVICES.
2. On the bottom toolbar, click NEW, and then click QUICK CREATE.
3. In the URL box, type a unique URL for the cloud service within the cloudapp.net domain.
4. In the REGION OR AFFINITY GROUP drop-down list, select a region close to the location of the
users of the cloud service.
5. Click CREATE CLOUD SERVICE.

Alternatively, you can create a PaaS cloud service by using the New-AzureService PowerShell cmdlet, as
shown in the following example.
New-AzureService -ServiceName ‘MyNewService’ -Location ‘East US’
Deploying service code

After they create a service, developers must deploy the compiled service code and the service
configuration file that define the settings of web and worker roles. Three common ways to perform this
deployment are:
• From Visual Studio, by using the Publishing Wizard. To ease this deployment method, you can obtain
a publish profile from Azure and import it into Visual Studio. This method uses Web Deploy to create
and configure web roles.
• From the Azure portal, by uploading a cloud service package and configuration file. Developers can
create these files by using the Packaging Wizard in Visual Studio. Administrators can use these files to
upload the service code and start the application.
• From Visual Studio Team Services, by configuring continuous deployment. If you choose this option,
take care to ensure that untested code is not accidentally deployed to the production environment.
Frequently, Visual Studio Team Services is configured to deploy code to a staging environment. After
the staged code has been tested, administrators can move it to the production environment.
Note: In the lab, you will see how to deploy a PaaS cloud service by using the Azure portal.
Managing deployment environments for PaaS cloud services

A PaaS cloud service runs in different locations
during development, testing, and production.
In each organization, development teams work
based on different project models. However, the
following divisions are commonly used.
During development
Most developers run informal tests on their code
as they develop it. These tests, which all the
developers on the team run repeatedly as they
modify code, are considered essential in many
organizations. Because developers run these tests
frequently, they code and run them in the IDE. At
this stage, the code runs on the developers’ computers.
For an Azure PaaS cloud service project, developers need an environment on their local computers that
closely matches Azure itself in which they can run tests. The Azure SDK provides such an environment.
This SDK has two important components, both of which start on the developer’s computer in debugging
mode:
• The Azure compute emulator. Web roles and worker roles run within this emulator.
• The Azure storage emulator. Blob storage, file storage, and table storage are simulated by this
emulator.
During staging
Staging is the last opportunity to test a project before it is deployed to production. The following tests are
commonly performed at this stage:
• Acceptance testing. These tests check that the completed project satisfies the functional and
nonfunctional requirements.
• Performance testing. These tests simulate user demand and determine the CPU, memory, and other
resources that might be required to cope with the expected load.
• Beta testing. A limited number of the final users of the project are granted access to the staging
environment to try out the software and identify issues.
For an Azure PaaS cloud service project, the staging environment should be in Azure itself—so you must
deploy the project. You can use a staging slot for this deployment. A staging slot is a deployment of the
cloud service with the following characteristics:
• In the Azure portal, it appears within a single cloud service, together with the production slot.
• To access the cloud service in the staging slot, you use a URL that includes the GUID. For example,
if your cloud service is found at http://myservice.cloudapp.net, the staging slot is found at
http://GUID.cloudapp.net. You can determine the GUID by browsing the service’s dashboard in
the Azure portal.
Alternatively, you can create a separate PaaS cloud service for staging. By using a staging slot, when all
the tests have passed, you can deploy the service to production by using a virtual IP (VIP) address swap. In
this operation, the staging and production slots are swapped, which means that the accepted new version
is moved to production without a new deployment of the code.
During production
The production environment is the final destination for the PaaS cloud service code. This environment
runs thoroughly tested and debugged code that your team has complete confidence in and services real
user requests based on live data and configuration settings.
Demonstration: Creating and deploying PaaS cloud services

• Create a new PaaS cloud service by using Azure PowerShell.

• Configure and package a cloud service project in Visual Studio 2015.
• Deploy a packaged cloud service project by using the Azure portal.
Demonstration Steps
Create a new PaaS cloud service by using Azure PowerShell
1. Start Windows Internet Explorer, browse to the Azure classic portal, and then sign in by using the
Microsoft account that is either the service administrator or a co-administrator of your Azure
subscription.
2. In the Azure classic portal, point out that no PaaS cloud services are configured.
3. Start Windows PowerShell as an Administrator from the taskbar.
4. From the Azure PowerShell session, sign in with the same Microsoft account that is either the service
administrator or a co-administrator of your Azure subscription.
5. Use the Get-AzureLocation cmdlet to identify the Azure region closest to your location, and then
note the region’s name.
6. Use the New-AzureService cmdlet to create a new cloud service named SmallCloudServiceXXX,
where XXX is a unique sequence of characters (digits or letters) in the region you identified in the
previous step.
7. Use the New-AzureStorageAccount cmdlet to create a new storage account named

smallcsstoragexxx, where xxx is unique sequence of characters (digits or lowercase letters) in the same
region.
8. Point out that the service has been created by showing it in the Azure classic portal.
Configure and package a cloud service project in Visual Studio 2015

1. From Visual Studio 2015, open the SmallCloudService.sln solution residing in the
D:\Demofiles\Mod08\SmallCloudService\ folder.
2. In Solution Explorer, view the properties of SmallWebRole.
3. In the Settings section of the SmallWebRole properties, create a connection string pointing to the
smallcsstoragexxx storage account you created earlier in this demo.
4. Save your changes.
5. In Solution Explorer, create a package for deploying the current solution.
Deploy a packaged cloud service project by using the Azure portal

1. Switch back to the Azure classic portal.
2. From the Azure classic portal, upload the newly created package to the Production deployment of
the SmallCloudServiceXXX you created earlier in this demo. Make sure to select the Deploy even if
one or more roles contain a single instance option.
Note: You need to enable the Deploy even if one or more roles contain a single
instance option because the demo role contains a single virtual machine instance.
Updating PaaS cloud services

After they deploy the first version of a PaaS cloud
service, developers tend to continue modifying
the code. Changes can include new features, bug
fixes, efficiency improvements, code that utilizes
new features of the Azure platform, or code that
implements real-world user feedback.
To deploy a new version of a PaaS cloud service to

Azure, you must upload the compiled package file
and configuration file in the same way that you
did when deploying the first version. You can do
this by using the Publishing Wizard in Visual
Studio, by manually uploading the files in the
Azure classic portal, or by using continuous deployment in Visual Studio Team Services. Regardless of the
approach, you should use a staging slot to evaluate the functionality and performance of the new version
before promoting it to production.
Staging slots provide an extra advantage when deploying updated services. When you move the staged
code into the production slot by performing a VIP address swap, the older version of the service is
automatically moved into the staging slot and not overwritten. In the event of any problem with the new
version, you can easily roll back the deployment to the old version by swapping again. In addition, the VIP
address swap does not take a significant amount of time, eliminating potential downtime associated with
the staging process.
Note that unlike with app services, staging functionality is implemented by using dedicated virtual
machines, which means you have the option to test deployments without affecting the performance of
the production services.
Question: Now that you understand the development, staging, and production
environments that the Azure SDK and Azure itself provide, you can consider how your own
organization might use them. The instructor will lead a discussion based on the following
questions. Contribute to the discussion by describing how development, staging, and
production environments are currently built in your company, and consider how your testing
policies can be implemented in Azure. Here are the questions:
How are on-premises applications separated for testing, staging, and production
deployments in your organization?
How are cloud applications separated for testing, staging, and production deployments in
your organization?
How will Azure modify your approach to testing, staging, and production deployment?
Lesson 2
Managing and maintaining cloud services
Developers create and modify code that defines PaaS cloud services, but Azure administrators must be
able to configure and manage their deployments. For example, administrators must ensure that a cloud
service is able to accommodate expected and unexpected peaks in demand. In this lesson, you will see
how to configure a cloud service by using configuration files and the Azure classic portal.
Lesson Objectives
At the end of this lesson, you will be able to:
• Modify a PaaS cloud service by making changes to the service configuration file.
• Explain how to manage endpoints and queues.
• Describe how to add a PaaS cloud service to a VNET.
• Explain how to configure the monitoring of PaaS cloud services.

• Describe how to monitor PaaS cloud services.
Modifying configuration files

When you deploy a PaaS cloud service to Azure,
you upload two files:
• The package file. This file contains the

compiled code for web roles and worker
roles.
• The configuration file. This file contains

configuration settings that Azure uses when
it starts instances of the roles of the cloud
service.
The configuration file that is used in development

is typically not appropriate for staging or
production. Visual Studio automatically generates two versions of the file: ServiceConfiguration.Local.cscfg
is for local development and ServiceConfiugration.Cloud.cscfg is for deployment to Azure. If you need to
modify the configuration settings after development is completed, you can accomplish this in several
ways:
• Edit the file directly. The configuration file is an .xml file, so you can use any text editor to make
changes.
• Edit many values in the Azure portal after deployment.
• Use the Visual Studio Publishing Wizard. Its friendly interface helps to simplify adjusting the
parameters of connection strings.
The following code shows a simple PaaS cloud service configuration file:
Example Service Configuration File

<ServiceConfiguration serviceName="ContosoAdsCloudService"
xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration"
osFamily="4"
osVersion="*"
schemaVersion="2014-01.2.3">
<Role name="ContosoAdsWeb">
<Instances count="1" />
<ConfigurationSettings>
<Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString"
value="UseDevelopmentStorage=true" />
<Setting name="StorageConnectionString"
</ConfigurationSettings>
</Role>
<Role name="ContosoAdsWorker">
<Instances count="1" />
<ConfigurationSettings>
<Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString"
<Setting name="StorageConnectionString"
<Setting name="ContosoAdsDbConnectionString"
value="Data Source=(localdb)\v11.0; Initial Catalog=ContosoAds;
Integrated Security=True; MultipleActiveResultSets=True;" />
</ConfigurationSettings>
</Role>
</ServiceConfiguration>
The preceding example shows a typical configuration file used in the development environment. Only one
instance of each role is configured, and connection strings use the Azure storage emulator and a local
database.
A configuration file used for an Azure deployment includes different values for the following parameters:
• Instance count. You should always use two or more instances of every role in the production
environment. This considerably improves resilience and qualifies the service for the 99.95 percent
uptime guarantee stipulated in the Azure SLAs. Use the Count attribute of the <Instances> tag to
specify the number of instances for each role.
• Database connection strings. You must ensure that the database connection strings point the cloud
service to the production database. This database can be an Azure SQL Database instance or a SQL
Server instance running in an IaaS virtual machine. When using an Azure SQL Database instance, you
can copy its connection string from its settings displayed in the Azure portal.
• Storage connection strings. If the service uses an Azure storage account, you must ensure that the
storage connection strings point the cloud service to the production storage account. You can copy
the connection string designating a storage account from its settings displayed in the Azure portal.
Managing endpoints and queues

Although web roles and worker roles in an
Azure PaaS cloud service run on different virtual
machines, you must ensure that they can reliably
communicate. One way to accomplish this
objective is to allow for direct connectivity, where
a role calls an endpoint on another role. Another
commonly used approach involves indirect
communication via a queue. Software architects
and developers typically choose the most-
appropriate connectivity mechanism. However,
as an administrator, you must be familiar with the
different options available for PaaS cloud services
to properly manage the necessary Azure resources.
Direct communication
Roles can communicate directly. For example, a web role can service a user request by calling a method in
a worker role. To enable this type of communication, you must create an endpoint in the destination role.
Endpoints come in three types:
• Input endpoints. These external, load-balanced endpoints enable Azure services and any Internet-
connected clients outside the PaaS cloud service to call the role via a designated protocol (TCP, UDP,
HTTP, or HTTPS) on a specific port.
• Internal endpoints. These endpoints enable roles within the same PaaS cloud service to directly
communicate via a designated protocol (TCP, UDP, HTTP, or combination of these) on a specific port.
• Instance input endpoints. These endpoints enable Azure services and any Internet-connected clients
outside the PaaS cloud service to call a specific instance of a role via a designated protocol (TCP or
UDP) on a specific port.
You can administer endpoints in the PaaS cloud service configuration file. For example, the following XML
code defines an internal endpoint for a worker role.
Worker Role Endpoint Definition

<WorkerRole name="ImageProcessorRole">
<Endpoints>
<InternalEndpoint name="InternalImageIn" protocol="tcp" port="1000"/>
</Endpoints>
</WorkerRole>
The following XML code defines an external endpoint for a web role.
Web Role Endpoint Definition

<WebRole name="FrontEndRole">
<Endpoints>
<InputEndpoint name="HttpIn" protocol="http" port="80" localPort="80" />
</Endpoints>
</WebRole>
Using Storage queues and Service Bus queues

Instead of using direct communication, developers and software architects might choose to use a queue
to send messages from one role to another. By using a queue, you help ensure that a message reaches a
role: the role works its way through all the messages in the queue asynchronously. You can also control
the processing of messages in a queue—for example, by throttling the throughput to help ensure that the
queue processing task does not consume all virtual machine resources. Therefore, a queue is a popular
communication method.
Two commonly used types of queues offered by Azure are Storage queues and Service Bus queues.
Developers and software architects usually decide which queuing mechanism to use. However, IT
professionals should be aware of these two options and be able to configure them as dependencies when
a cloud service uses them. The following table shows basic differences between Azure Storage queues and
Service Bus queues.
Characteristic Storage queue Service Bus queue
Average latency 10 milliseconds (ms) 100 ms
Maximum message size 64 kilobytes (KB) 256 KB
Maximum queue size 1 terabyte (TB) 5 gigabytes (GB)
Maximum message Time to Live Seven days Unlimited

(TTL)
Additional Reading: For more information about the differences between Storage queues
and Service Bus queues, see: Azure Queues and Service Bus queues - compared and contrasted at
http://aka.ms/Wgyq5f.
Adding a PaaS Cloud service to a VNET

By default, a PaaS cloud service is not directly
accessible from any IaaS virtual machines or other
cloud services in your Azure subscription. The
PaaS cloud service can communicate with those
virtual machines or other cloud services in the
same way that external clients can—by using a
public endpoint.
Alternatively, you can choose to enable direct

communication between a PaaS cloud service and
an Azure IaaS virtual machines as well as other
PaaS cloud services by placing all of them into a
single IaaS V1 VNET or into interconnected VNETs.
To learn more about VNETs, refer to Module 2. Keep in mind that PaaS cloud services are not compatible
with IaaS V2 VNETs.
By using a VNET to place a PaaS cloud service directly into a VNET, you can:
• Reduce the latency of communications among PaaS cloud services and IaaS virtual machines, because
communication is direct and does not traverse public endpoints and the Azure load balancer.
• Enable on-premises clients to connect directly with a PaaS cloud service. This is possible if the VNET
has connectivity to your on-premises network via a site-to-site VPN or ExpressRoute.
To add a PaaS cloud service to a VNET, you must add a <NetworkConfiguration> section to the service
configuration file. You must insert this section after all the roles have been defined in the file.
In the following example, the service configuration file determines that the current PaaS cloud service will
be added to the A. Datum HQ VNET.
Adding a PaaS Cloud Service to a VNET

<NetworkConfiguration>
<VirtualNetworkSite name="AdatumHQ" />
<AddressAssignments>
<InstanceAddress roleName="SimpleWebRole">
<Subnets>
<Subnet name="HQSubnet1" />
</Subnets>
</InstanceAddress>
</AddressAssignments>
</NetworkConfiguration>
Note: You must add one <InstanceAddress> element to the <NetworkConfiguration>

element for every role in your cloud service.
Demonstration: Scaling PaaS cloud services

• Set the default instance count for a cloud service.

• Schedule a larger instance count for an expected load peak.
Note: The scheduled scaling technique in this demonstration helps to ensure that sufficient
instances of all the roles are present to maintain consistent responsiveness during an expected
peak in demand. After the peak passes, instances are automatically deprovisioned to avoid extra
costs. When you set the schedule, bear in mind that it can take a few minutes for each new
instance to come online. Start your schedule before the expected peak to help ensure that the
full capacity is reached in a timely manner.
Demonstration Steps
Set the default instance count for a cloud service

1. Start Internet Explorer, browse to the Azure classic portal, and then sign in by using the Microsoft
account that is either the service administrator or a co-administrator of your Azure subscription.
2. In the Azure classic portal, navigate to the SmallCloudServiceXXX cloud service you created in the
previous demo (where XXX is a sequence of three characters—letters or digits—that you have chosen
to make the name unique).
3. Scale out the cloud service to two instances.
Note: Wait a few minutes until the new instance is provisioned.
Schedule a larger instance count for an expected peak in demand

1. Create a schedule, named Demo Schedule, for scaling for the SmallCloudServiceXXX cloud service
with the following settings:
o START AT: Today’s date
o START TIME: 10 minutes from the current time

o END AT: Today’s date
o END TIME: 40 minutes from the current time.
2. Set the number of instances for Demo Schedule to three.
Note: The portal interface might continue to display the calendar day picker even after
the schedule is set and saved. If you see this issue, refresh the Internet Explorer window by
pressing F5.
3. Show the number of instances automatically increasing.

1. Launch Windows PowerShell as Administrator
Reset-Azure
recommend that you use an Azure trial pass that was provisioned specifically for this course,
The script will take 5-10 minutes to reset your Microsoft Azure environment, ready for the
next lab.
Configuring the monitoring of PaaS cloud services

Cloud services might need to support large
numbers of users and continue to respond quickly
even during increased demand. You should be
able to monitor the performance of your service
to help ensure that users have a satisfactory
experience.
Azure provides built-in monitoring functionality

for every PaaS cloud service. You can use this
capability to determine how the cloud service is
using virtual machine resources.
Minimal monitoring
By default, PaaS cloud services offer minimal monitoring. In this mode, performance data can be collected
for the following counters:
• CPU (percentage)
• Disk read throughput (bytes/second)

• Disk write throughput (bytes/Second)
• Network in (bytes)
• Network out (bytes)
If you have multiple role instances, you can monitor these counters either for individual instances or in
aggregate values for all the instances of each role. Monitoring is configured separately for the production
and staging deployments.
Verbose monitoring
When you enable verbose monitoring, you can record a much larger range of counters. This allows you to
gain a much more detailed picture of the performance of instances and roles. Unlike minimal monitoring,
verbose monitoring stores data in table storage. Therefore, you must create a storage account and
connect it to the monitoring tool to use verbose monitoring.
Note: Minimal monitoring is free. However, because verbose monitoring stores data in a
storage account, it incurs extra costs for using the Azure Storage service.
To configure verbose monitoring:
1. In the Azure classic portal, in the left navigation bar, click STORAGE, and then click the storage
account you want to use to store monitoring data.
2. In the bottom command bar, click MANAGE KEYS.
3. Next to the storage account key, click Copy, and then click Allow access.
4. In the left navigation bar, click CLOUD SERVICES, and then click the PaaS cloud service you want to
monitor.

6. In the DIAGNOSTIC CONNECTION STRINGS section, modify the existing entry by replacing the
name of the storage account following AccountName= string and replacing the storage account key
following the AccountKey= string.
7. Click SAVE.
8. In the Monitoring section, click VERBOSE.
9. Click SAVE.
Monitoring PaaS cloud services

You can view metrics representing your
monitoring configuration in the Azure classic
portal. This allows you to quickly determine their
state over the last hour, day, or seven days. You
can also add alerts to metrics that the portal
displays. As part of the alert rule configuration,
you have the option to automatically send an
email to arbitrary recipients if a metric exceeds a
threshold that you designate.
To add a metric to the monitoring table:
1. In the Azure classic portal, in the left

navigation bar, click CLOUD SERVICES.
2. Click the PaaS cloud service you want to monitor, and then click the MONITOR tab.
3. In the command bar at the bottom, click ADD METRICS.
4. In the list of roles, choose the role instance or instances you want to monitor. You can also select
aggregated counters for all the instances of each role.
5. Expand the metrics section that interests you, and then select the metric to add.
6. Click Yes.
After you have added a metric to the table, configure an alert for that metric by following these steps:
1. In the list of metrics on the MONITOR tab, select the metric that interests you.
2. In the command bar at the bottom, click ADD RULE.
3. In the NAME box, type a descriptive name for the alert, and then click Next.
4. In the CONDITION drop-down list, select the condition that will determine whether the
corresponding alert gets triggered.
5. In the THRESHOLD VALUE box, type a value corresponding to the condition that will trigger the
alert.
6. In the ACTIONS section, choose whether to send an email to the service administrator and co-
administrators or to another, arbitrary email address.
7. Click Complete.

Question
What should you do to deploy a PaaS cloud service into an existing VNET?
Modify the cloud service package file (.cspkg file).
Modify the cloud service configuration file (.cscfg file).
Add an internal endpoint to the cloud service roles.
Add an instance input endpoint to instances of cloud service roles.
Add an input endpoint to the cloud service.

Lab: Implementing PaaS cloud services

Scenario
You want to evaluate the capabilities of PaaS cloud services to host A. Datum web applications. Your
development team has provided a simple cloud service project that you can use to test its functionality in
Azure. You want to show how staging and production slots can be used to simplify the deployment of
new versions of the cloud service. You also want to determine whether you can monitor the service to get
clear information on resource usage.
Objectives
At the end of this lab, you will be able to:
• Configure and deploy a PaaS cloud service to Azure.
• Deploy a PaaS cloud service for staging and enable Remote Desktop Protocol (RDP) access.
• Configure metrics and alerts to monitor PaaS cloud service behavior.

User name: Student
Password: Pa$$w0rd
Exercise 1: Deploying a PaaS cloud service

Scenario
You have been asked to test the deployment of the sample PaaS cloud service to Azure.
1. Create a linked resource for a PaaS cloud service.
2. Configure the service definition file.
3. Deploy the PaaS cloud service.
 Task 1: Create a linked resource for a PaaS cloud service

1. Sign in to the MIA-CL1 lab virtual machine as Student with the password Pa$$w0rd.
2. Start Windows PowerShell as an Administrator.
3. Sign in to your Azure subscription from the Windows PowerShell window.
4. Identify the Azure region closest to your location, where you can create a storage account and a SQL
database.
5. From the Windows PowerShell session, create a new Azure SQL Database server. Set the name of the
Administrator account to match your name. Set the password to Pa$$w0rd. Set the location to the
Azure region you identified in the previous step.
6. From the Azure portal, create a new Azure SQL Database named CloudServiceProdDB on the newly
created server. Use the default settings.
7. From the Windows PowerShell session, create a new IaaS V1 storage account with default settings.
Name the account cloudappprodxxx, where xxx is a unique sequence of characters (digits or
lowercase letters). Use the same region you identified in step 4.
 Task 2: Configure the service definition file

1. Launch Visual Studio 2015, and then open the ServiceConfiguration.Cloud.cscfg file located in
D:\LabFiles\Lab08\Starter\Production\Package.
2. In the file, set the Instance count attribute for the AdatumAdsWebRole and
AdatumAdsWorkerRole roles to 2.
3. Launch Internet Explorer, and then sign in to the Azure classic portal with the service administrator
account of your Azure subscription.
4. Locate the storage account created in the previous task, and then copy its Primary Access Key to the
Clipboard.
5. Switch back to Visual Studio, and then replace every occurrence of the following string:
UseDevelopmentStorage=true
Use the following string (on a single line) as the replacement:
DefaultEndPointsProtocol=https;
AccountName=cloudappprodxxx;AccountKey=keyvalue
In the replacement, cloudappprodxxx is the name of the storage account you created in the previous
task, and keyvalue is the Primary Access Key you copied to the Clipboard.
6. Launch Internet Explorer, and then sign in to the Azure portal with the service administrator account
of your Azure subscription.
7. Identify the ADO.NET connection string for the CloudServiceProdDB SQL database you created in
the first task of this exercise.
8. Copy the connection string to the Clipboard.
9. Locate the value of the Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString element

of the AdatumAdsWebRole role in the ServiceConfiguration.Cloud.cscfg file.
10. Replace the file of the Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString element

with the ADO.NET connection string copied to the Clipboard.
11. In the connection string you just pasted, locate the text {your_password_here}.
12. Delete the located text, and then replace it with Pa$$w0rd.
13. Save ServiceConfiguration.Cloud.cscfg.
 Task 3: Deploy the PaaS cloud service

1. From the Azure classic portal, create a new, PaaS cloud service in the same region you identified in
the first task of this lab. Set the name to that of the cloud service matching your name, followed by
today’s date in the MMDDYY format. Use the Deploy a cloud service package option.
2. Set the production deployment name to AdatumAdsProd.
3. Upload the package AdatumAds.cspkg from D:\LabFiles\Lab08\Starter\Production\Package.
4. Upload the configuration file ServiceConfiguration.Cloud.cscfg from

D:\LabFiles\Lab08\Starter\Production\Package.
5. Wait for the deployment to take effect.
Note: The deployment process for the PaaS cloud service can take several minutes to
complete. Watch the cloud services page. Wait for the Service Status column to display
Created and the Production column to display Running before you continue to the next task.
Results: You created a storage account and a SQL database, edited the service configuration file, and
deployed the cloud service to the production slot.
Exercise 2: Configuring deployment slots and RDP

Scenario
The development team has provided a second version of the PaaS cloud service you deployed. You want
to determine how you can use deployment slots to stage and deploy new versions of cloud services. You
will use the same configuration you used for the production service.
1. Perform a staged deployment of a PaaS cloud service.
2. Configure RDP access.

3. Test connectivity.
 Task 1: Perform a staged deployment of a PaaS cloud service

1. From the Azure classic portal, add a new staging deployment to the newly created PaaS cloud service
by uploading package and configuration files.
2. Set the staging deployment name to AdatumAdsStage.
3. Upload the package AdatumAds.cspkg from D:\LabFiles\Lab08\Starter\Staging\Package.
4. Upload the configuration file ServiceConfiguration.Cloud.cscfg from D:\LabFiles\Lab08\Starter

\Production\Package.
5. Wait for the deployment to take effect.
complete. Watch the cloud services page. Wait for the Staging column to display Running
before you continue to the next task.
 Task 2: Configure RDP access

1. From the Azure classic portal, enable Remote Desktop for all the roles of the production deployment
of the PaaS cloud service created in the previous exercise of this lab.
2. Set the Remote Desktop user name to RDPAdmin.
3. Set the Remote Desktop password to Pa$$w0rd.
4. Set the expiration date to one month from today’s date.

 Task 3: Test connectivity

1. From the Azure classic portal, identify the URL of the production deployment of the PaaS cloud
service you deployed in the previous exercise.
2. Use Internet Explorer to navigate to the URL representing the production deployment of the PaaS
cloud service.
3. Leave the Internet Explorer window open. You will use it later in this exercise.
4. From the Azure classic portal, identify the URL of the staging deployment of the PaaS cloud service
you deployed in the previous exercise.
5. Navigate to the URL representing the staging deployment of the PaaS cloud service by using Internet
Explorer.
6. Close the Internet Explorer tab showing the staging deployment.
7. Connect via Remote Desktop to the AdatumAdsWebRole_IN_0 instance of the production

deployment.
8. Close the remote desktop connection.
Results: At the end of this exercise, you will be able to:
• Perform a staging deployment of a PaaS cloud service.

• Enable RDP access to a PaaS cloud service.
• Connect to production and staging instances via HTTP and via RDP.
Exercise 3: Monitoring cloud services

Scenario
You have been asked to evaluate the network traffic used by the new version of the PaaS cloud service
that you deployed to the production environment. To accomplish this, you will start collecting network-
related monitoring metrics and configure an alert.
1. Add metrics to the PaaS cloud service monitoring.
2. Create an alert.
3. Monitor an active cloud service.
 Task 1: Add metrics to the PaaS cloud service monitoring

1. In the Azure classic portal, navigate to the MONITOR tab of the production deployment of the PaaS
cloud service created in the first exercise of this lab.
2. Add the Network In metric of the aggregate for AdatumAdsWebRole to the list of metrics
displayed on the MONITOR tab in the portal.
 Task 2: Create an alert

1. From the Azure classic portal, add a rule for the Network In metric for the aggregate of
AdatumAdsWebRole.
2. Name the rule Network In Alert.
3. Set the threshold value of the rule to 1.
4. Configure the rule to send alerts to the email address of the service administrator account of your
Azure subscription.
5. Keep the remaining values at their defaults.
6. Generate network traffic to the production deployment by accessing it via HTTP, using its webpage
displayed in Internet Explorer, which you opened earlier in this exercise.
Note: It might take a few minutes before the alert is triggered.
 Task 3: Monitor an active cloud service

1. From the Azure classic portal, navigate to MANAGEMENT SERVICES, and then view the Network In
Alert rule you created in the previous task.
2. Review the alerts generated by the rule.
3. From Internet Explorer, navigate to the Microsoft Outlook mailbox of the service administrator
account of your Azure subscription.
4. Review the email alerts generated the rule.
5. Close Internet Explorer, which is displaying the content of the Outlook mailbox.

1. Launch Windows PowerShell as an Administrator.
2. From the Windows PowerShell prompt, run the following command:
Reset-Azure
Note: This script removes Azure services from your subscription. It is therefore
recommended that you use an Azure trial pass that was provisioned specifically for this course
The script takes 5–10 minutes to reset your Azure environment so that it is ready for the next
lab. The script removes all storage, virtual machines, VNETs, cloud services, and resource groups.
Important: The script might not be able to get exclusive access to a storage account to delete it.
(If this occurs, you will see an error.) If you find objects remaining after the reset script is
complete, you can rerun the Reset-Azure script or use the Azure portal and the Azure classic
portal to manually delete all the objects in your Azure subscription—with the exception of the
default directory.
Results: At the end of this exercise, you will have configured monitoring for a PaaS cloud service with new
metrics and an alert.
Question: In Exercise 2, you enabled RDP access and used the RDP client to connect to an
instance of a web role. Why would administrators connect to cloud service role instances
with RDP?
Question: You want to ensure you can identify the volume of network traffic your PaaS
cloud service has received over the last hour. Should you configure a monitoring metric or
an alert?

In the module, you learned about:
• Planning, creating, and deploying PaaS cloud services.
• Configuring cloud services by using configuration files or the Azure portal.
Review Question
Question: Your organization plans to develop a new multi-tier IIS-based application and
deploy it to Azure. The application must be able to scale each tier independently. You need
to minimize the ongoing maintenance of the operating system. You also want to be able to
choose arbitrary virtual machine sizes for each tier. In addition, the application must operate
within a VNET to allow communication with IaaS virtual machines. What host application
model should you use?
9-1
Module 9
Implementing Azure Active Directory
Contents:
Module Overview 9-1
Lesson 1: Creating and managing Azure AD tenants 9-2
Lesson 2: Configuring application and resource access with Azure AD 9-14
Lesson 3: Overview of Azure AD Premium 9-23
Lab: Implementing Azure AD 9-31
Module Overview
Microsoft Azure Active Directory (Azure AD) is a cloud-based identity and access management solution.
By using Azure AD, you can provide secure access to sensitive services and data with multi-factor
authentication and single sign-on (SSO). This makes application access more convenient for the end users.
In this module, you will learn how to create a custom domain, integrate applications with Azure AD, and
use Azure AD Premium features. You will also implement Azure Role-Based Access Control (RBAC) to
users, groups, and applications at the right scope.
Objectives
• Create and manage Azure AD tenants.

• Configure SSO for cloud applications and resources, and implement RBAC for cloud resources.
• Explain the functionality of Azure AD Premium, and implement Azure Multi-Factor Authentication.
9-2 Implementing Azure Active Directory
Lesson 1
Creating and managing Azure AD tenants
Azure AD provides identity and access services for the resources that exist in the cloud. Azure AD is an
identity management solution that spans on-premises and in cloud. It provides you with application
access control, federation, identity management, user provisioning, information protection, standard
protocols support, comprehensive development libraries, and many other features. In this lesson, you will
learn about the capabilities that Azure AD offers.
Lesson Objectives
• Explain about the purpose of Azure AD.
• Identify the similarities and differences between Active Directory Domain Services (AD DS) and
Azure AD.
• Explain how to manage users, groups, and devices by using the Azure portal and Microsoft Azure
PowerShell.
• Explain how to manage multiple Azure AD tenants.
• Explain how to implement Azure AD Business to Business (B2B) and Azure AD Business to Consumer
(B2C).
Demonstration: Preparing the Microsoft Azure environment

Perform the tasks in this demonstration to prepare the lab environment. The Microsoft Azure services you
will use in the lab will be described in this module while the environment is being configured.
Important: The scripts used in this course might delete objects that you have in your
Microsoft account that has not been associated with any other Azure subscription. This will
eliminate the possibility of confusion when running setup scripts.
The labs in this course use custom Azure PowerShell cmdlets including Setup-Azure to prepare the Azure
environment for a lab, and Reset-Azure to perform clean-up tasks at the end of a lab. Setup-Azure
removes any current Azure subscription and account references from the Azure PowerShell session.
• Sign in to your Microsoft Azure subscription.

Demonstration Steps

1. On MIA-CL1, on the taskbar, right-click Windows PowerShell, and then click Run as administrator.
In the User Account Control dialog box, click Yes.
Setup-Azure
The script will take a few seconds to configure your Azure environment, which will be ready to use for
the lab at the end of this module.
Active Directory as a component of Azure

Azure AD provides identity and access services for
the resources that exist in the cloud. Azure AD has
many similarities to AD DS in terms of providing a
solution for SSO access to thousands of cloud
Software as a Service (SaaS) applications.
Organizations can use Azure AD to improve

employee productivity, streamline IT processes,
and improve security for adopting various cloud
services. Employees can access online applications
by using a single user account. User management
can be done centrally by using well-known
Windows PowerShell cmdlets. Furthermore, Azure
AD is highly scalable and highly available by design. Therefore, organizations do not have to maintain
related infrastructure or worry about disaster recovery.
As a component of Azure, Azure AD can support multi-factor authentication as part of an overall access
strategy for the cloud services, thus providing an additional layer of security. RBAC, self-service password
and group management, and device registration provide enterprise-ready identity management solutions.
Many applications built on different platforms such as .Net, Java, Node.js, and PHP can use industry
standard protocols such as Security Assertion Markup Language (SAML) 2.0, WS-Federation, and OpenID
Connect to integrate the identity management provided by Azure AD into the application logic. Through
the support of OAuth 2.0, developers can develop mobile and web service applications that integrate with
Microsoft’s identity platform for cloud authentication and access management.
Organizations that use AD DS can integrate users and groups from the local Active Directory domain with
Azure AD to enable a SSO experience for the users while accessing both on-premises and cloud-based
applications.
Overview of Azure AD
Azure AD is multitenant cloud-based identity and
access management solution for the Azure
platform. You can use it to provide secure access
for organizations and individuals. You can use
Azure AD to:
• Configure access to applications.

• Configure SSO to cloud-based SaaS
applications.
• Manage users and groups.
• Provision users.
• Enable federation between organizations.
• Provide an identity management solution.

• Identify irregular sign-in activity.
• Configure multi-factor authentication.
• Extend existing on-premises Active Directory implementations to Azure AD.
The directory component of Azure AD is, by design, multitenant, and it provides a highly scalable cloud-
based directory service:
• Multitenant. Microsoft hosts millions of users and directories within Azure AD. However, because each
Azure AD directory is distinct and separate from other Azure AD directories, customer data and
identity information is completely isolated from other tenants to prevent users and administrators of
one Azure AD directory from accidentally or maliciously accessing data in another directory.
• Scalable. The directory technologies that Azure AD uses are also used by Microsoft Office 365 and
Microsoft Intune to support millions of users. The flexible, extensible data model of Azure AD uses the
REST-based Graph API, not Lightweight Directory Access Protocol (LDAP).
Azure AD editions
To meet customers' different needs and expectations, Azure AD comes in three editions:
• The Free edition provides user and group management, device registration, self-service password
change, and synchronization with on-premises directories. It is limited to 10 applications per user
configured for SSO.
• The Basic edition extends the free edition’s capabilities by combining group-based access
management, self-service password reset for cloud applications, and usage of application proxy.
Additionally, this edition has a Microsoft high availability service level agreement (SLA) uptime of
99.9%.
• The Premium edition is designed to accommodate organizations with more demanding identity and
access management needs. It supports dynamic groups and self-service group management, self-
service password reset with password writeback, Cloud App Discovery, Azure Active Directory
Connect Health, and advanced reports for security and usage information.
AD DS
AD DS is the traditional deployment of Windows Server-based Active Directory on a physical or virtual
server. Although AD DS is commonly considered to be primarily a directory service, it is only one
component of the Windows Active Directory suite of technologies, which also includes Active Directory
Certificate Services (AD CS), Active Directory Lightweight Directory Services (AD LDS), Active Directory
Federation Services (AD FS), and Active Directory Rights Management Services (AD RMS).
When comparing AD DS with Azure AD, it is important to note the following characteristics of AD DS:
• AD DS is a true directory service, with a hierarchical X.500-based structure.
• AD DS uses Domain Name System (DNS) for locating resources such as domain controllers.
• AD DS can be queried and managed through LDAP calls.
• AD DS primarily uses Kerberos for authentication.

• AD DS uses organizational units (OUs) and Group Policy Objects (GPOs) for management.
• AD DS includes computer objects, representing computers that join an Active Directory domain.
• AD DS uses trusts between domains for delegated management.
You can deploy AD DS on an Azure virtual machine to enable scalability and availability for an on-
premises AD DS. However, deploying AD DS on an Azure virtual machine does not make any use of Azure
AD. Note that deploying AD DS on an Azure virtual machine requires one or more additional Azure data
disks because you should not use the C drive for AD DS storage. These disks are needed to store the AD
DS database, logs, and SYSVOL. The Host Cache Preference setting for these disks must be set to None.
Azure AD
Although Azure AD has many similarities to AD DS, there are also many differences. It is important to
realize that using Azure AD is not the same as deploying an Active Directory domain controller on an
Azure virtual machine and adding it to your on-premises domain.
When comparing Azure AD with AD DS, it is important to note the following characteristics of Azure AD:
• Azure AD is primarily an identity solution, and it is designed for Internet-based applications by using
HTTP (port 80) and HTTPS (port 443) communications.
• Azure AD users and groups are created in a flat structure, and there are no OUs or GPOs.
• Azure AD cannot be queried through LDAP; instead, Azure AD uses the REST API over HTTP and
HTTPS.
• Azure AD does not use Kerberos authentication; instead, it uses HTTP and HTTPS protocols such as
SAML, WS-Federation, and OpenID Connect for authentication (and OAuth for authorization).
• Azure AD includes federation services, and many third-party services (such as Facebook) are federated
with and trust Azure AD.
Federated applications are covered in Lesson 2 of this module. You can also federate your AD DS with
Azure AD. This is covered in Module 10 of this course.
Custom domain names

Administrators can add a custom domain name to their Azure AD tenant. You can add custom domain
names to an Azure AD tenant by using:
• A Microsoft cloud service portal, such as the Azure, Office 365, or Microsoft Intune management
portals.
• The Microsoft Azure Active Directory Module for Windows PowerShell.

To add a custom domain name to an Azure AD tenant by using a portal, perform the following steps:
1. In the Microsoft cloud service portal, specify the custom domain name.
2. In the Microsoft cloud service portal, note the DNS records that will need to be created at your
domain registrar or DNS hosting provider.
3. Sign in in to your domain registrar or DNS hosting provider, and create the DNS records.
4. In the Microsoft cloud service portal, verify that the Microsoft cloud service can resolve the newly
created DNS records for the custom domain.
Before you can verify a custom domain, the domain name must already be registered with a domain
name registrar, and the administrator must have appropriate sign-in credentials to be able to create DNS
records for this domain. Registration of a custom domain can be done with the domain registrar or with a
DNS hosting provider. These DNS records are required to verify the domain with the Microsoft cloud
service, and to point traffic to the cloud service. Azure AD provides the required DNS information, either
TXT (preferably), or MX records if your DNS provider does not support TXT records.
The following is an example of a TXT record used for custom domain verification:
Alias or Host name: @
Destination or Points to Address: MS=ms96744744
TTL: 1 hour
After verification, the administrator can make the domain the primary domain for the Azure tenant. For
example, you can replace adatum12345.onmicrosoft.com with adatum.com, so that new users will be
automatically created in this directory.
Managing Azure AD users, groups, and devices

You can manage Azure AD users, groups, and
devices by using the Azure portal, Microsoft Azure
Active Directory Module for Windows PowerShell,
and Microsoft Intune or Office 365. You can add
users to a directory, and also add users to groups.
There are essentially two ways to create and

manage your users:
• As cloud identities by using only Azure AD.

This is the quickest and most straightforward
method.
• As directory-synchronized identities by using

an on-premises directory service to synchronize with Azure AD. This method has the added
complexity of installing and configuring synchronization software to ensure that directory objects
synchronize successfully with Azure AD.
The Azure portal provides a simple web interface for creating and managing users, groups, and devices.
Creating users with the Azure portal

Using the Azure classic portal or the new Azure portal is the simplest method for creating single or small
numbers of user accounts.
To create a single user, perform the following steps:
1. In the portal, on the left pane, click Active Directory.
2. Click Users.
3. Click the + (Add) symbol.
4. Enter the following user information:
o Type of User: New user in your organization
o User name: unique name
o First Name/Last Name/Display Name: (choose appropriate values)
o Role: User
5. Click the Create button to finalize user creation. After the user is created, a temporary password
appears.
Managing devices in the Azure portal

Users can join their Windows 10 devices to Azure AD by themselves during the first-run experience or
from the system settings. If users sign in to Windows 10 by using their Azure AD credentials, they can
experience SSO to Office 365 and any other applications that use Azure AD for authentication, including
the Azure AD Access Panel (at myapps.microsoft.com).
Initially, you need to enable the option for users to join their devices to Azure AD on the Configure tab in
the Active Directory pane for your Azure subscription. You can also limit the maximum number of devices
per user (default is 20) and enable multi-factor authentication for joining devices in Azure AD.
After a device is registered in Azure AD, you can delete its Azure AD object or block its use by using the
portal. If the device is managed by Microsoft Intune or another mobile device management (MDM), you
can have additional capabilities such as pushing policies and software.
Managing users, groups, and devices by using Windows PowerShell

You can also manage users, groups, and devices by using Microsoft Azure Active Directory Module for
Windows PowerShell.
The following are required to run the Microsoft Azure Active Directory Module for Windows PowerShell:
• Operating system. You must be running either Windows 7 or newer, or Windows Server 2008 R2 or
newer.
• Microsoft .NET Framework. You must install the Microsoft .NET Framework 3.51 feature.
• Software updates. You must have installed all the updates required by the Microsoft cloud services to
which you have subscribed.
• Microsoft Online Services Sign-in Assistant. You must install the appropriate version of the Microsoft
Online Services Sign-in Assistant for your operating system from the Microsoft Download Center.
To connect to Azure AD, at the Microsoft Azure Active Directory Module for Windows PowerShell prompt,
type the following command, and then press Enter:
Connect-MsolService
You are then prompted for administrator credentials. In Windows PowerShell, you can create user
accounts by using Microsoft Azure Active Directory Module for Windows PowerShell commands as shown
below:
New-MsolUser -UserPrincipalName mledford@adatum.com -DisplayName "Mario Ledford"

-FirstName "Mario" -LastName "Ledford" -Password 'Pa$$w0rd123' -ForceChangePassword $false
-UsageLocation "US"
To create groups by using Microsoft Azure Active Directory Module for Windows PowerShell commands,
run the following cmdlet:
New-MsolGroup -DisplayName "Azure team" -Description "Adatum Azure team users"
Microsoft Azure Active Directory Module for Windows PowerShell also provides cmdlets for managing
devices registered in Azure AD. For example, to query all the devices that the user John owns, run the
following cmdlet:
Get-MsolDevice –RegisteredOwnerUpn John@contosomfa.onmicrosoft.com
To enable or disable registered devices, run the following cmdlet:
Enable-MsolDevice/Disbable-MsolDevice
To remove a device from management from Azure AD, run the following cmdlet:
Remove-MsolDevice -DeviceId a7892334-730b-4d49-bd13-54c2a4928009
Creating users by using bulk import

To create multiple users in bulk, you can either import a CSV file containing account information, such as
by exporting from an existing on-premise directory, or use Azure PowerShell scripting to generate
multiple accounts. To use bulk import, you first must assemble your user information, which might include
the following:
UserName FirstName LastName DisplayName JobTitle Department Country
AnneW@adatum.com Anne Wallace Anne Wallace President Management United

States
FabriceC@adatum.com Fabrice Canel Fabrice Canel Attorney Legal United

States
GarretV@adatum.com Garret Vargas Garret Vargas Operations Operations United

States
You then need to create a CSV file in the following format:
UserName,FirstName,LastName,DisplayName,JobTitle,Department,Country
AnneW@adatum.com,Anne,Wallace,Anne Wallace,President,Management,United States
FabriceC@adatum.com,Fabrice,Canel,Fabrice Canel,Attorney,Legal,United States
GarretV@adatum.com,Garret,Vargas,Garret Vargas,Operations,Operations,United States
You can then use Microsoft Azure Active Directory Module for Windows PowerShell commands to process
this CSV file and create the user accounts as shown below:
$users = Import-Csv C:\Users.csv

$users | ForEach-Object {
New-MsolUser -UserPrincipalName $_.UserName -FirstName $_.FirstName -LastName $_.LastName
-DisplayName $_.DisplayName -Title $_.JobTitle -Department $_.Department -Country
$_.Country
}
Managing multiple Azure AD tenants

When you sign up for Azure, Office 365, Microsoft
Dynamics CRM Online, or Microsoft Intune, you
get an Azure AD directory. That directory is used
to authenticate sign-in attempts. You can also
create additional directories as needed.
Support for multiple Azure directories, within the
same subscription, enables administrators to have
both a live production directory and another
directory for testing or non-production use or for
data synchronized from another AD forest.
Multiple directory support means that an
administrator can:
• Add a new directory for testing or other non-production usage, or for managing data synced from
another AD forest.
• Manage all existing Azure AD directories, such as Azure, Office 365, Microsoft Intune, by using the
same account—as long as the same account is a Global Administrator for all the directories.
• Change the name of a directory to be descriptive, or label it for non-production use, for example.
• Add users to a new Azure AD from an existing directory, such as to take users from a production
directory and use them in a test environment, without requiring those users to sign in with new
accounts and credentials.
Adding a new directory

To add a directory, sign in to the portal, select New, click Application Services, click Active Directory,
click Directory, and then click Custom Create. In the Add Directory dialog box, configure the basic
properties for your new directory such as its name, default domain name, and the country or region, and
then click the check mark to create the new directory.
Using an existing directory

To configure a Microsoft account to manage an existing directory, you first need to add your Microsoft
account as a Global Administrator of that directory. The subsequent steps are the same as adding a new
directory. In the portal, select New, click Application Services, click Active Directory, click Directory,
and then click Custom Create.
Then, in the Add Directory dialog box, in the Directory drop-down list, select Use existing directory.
You need to sign out and then sign in with the user name and password of the Global Administrator
account in the directory that you want to manage.
After you add an existing directory, you can make that directory to be the directory for your Azure
subscription, which will allow you to grant users from the organizational Azure AD permissions to
resources existing in the Azure subscription. In the Azure portal, in the Settings pane, select the
Subscription menu, select your subscription, click Edit Directory, and then select any existing directory
for your subscription.
You can manage each Azure AD as a fully independent resource, with administrative isolation and a
separate synchronization option. Creating and deleting a resource in one directory has no impact to any
resource in another directory.
Adding a user from another directory

Any Global Administrator of the newly created Azure AD directory can create new users or add users from
other directories.
To add a user from another directory:
1. Click Add User on the command bar.
2. In the Type of User drop-down list, select User in another Windows Azure AD directory.
3. Enter the user's user name.
4. Assign the role that the user needs in the target directory.
5. Click the check mark, which is on the right of the user name.
Deleting an Azure AD directory

By using a user account with global administrative rights, you can delete an Azure AD directory if the
following conditions are met:
• You deleted all the users in the directory except the Global Administrator for the directory that you
want to delete. The Global Administrator’s name cannot have the same suffix as the directory you
intend to delete.
• All applications configured for SSO are removed from the directory.
• The directory is not associated with any of the cloud services such as Azure, Office 365, or Azure AD
Premium.
• No multi-factor authentication providers are linked to the directory.
To delete an Azure AD directory, perform the following steps:
1. Select the directory you want to delete.

2. Click Delete on the command bar.
3. Confirm that the prerequisites are met by clicking the check mark.
Implementing Azure AD B2B and Azure AD B2C
Azure AD B2B
Azure AD B2B collaboration enables simple and
secure sharing of data and applications between
partners, regardless of the partners' current
infrastructure. Azure AD B2B uses an invitation
model to provide existing and new partner
companies access to your applications. It reduces
complexity by enabling companies to federate
once with Azure AD, and then use secure and
granular control over the applications that other
organizations can access.
The partner companies that need access to your corporate apps do not need to have Azure AD, because
the invitation model provides them with a simple user sign-up experience and immediate access to your
apps.
To allow external users to access your applications, you need to provide email addresses together with the
application ID for every application for which you want to allow external access. You prepare this
invitation by creating and uploading a .csv file to the Azure AD directory. After you upload the file, Azure
AD sends an email invitation to the users, with a link to accept the invitation.
Azure AD B2C
Azure AD B2C provides Identity as a Service (IDaaS) for your applications by supporting two industry
standard protocols, OpenID Connect and OAuth 2.0. Azure AD B2C eliminates the requirements for
developers to write a code for identity management and for storing identities in on-premises databases or
systems. It simplifies and standardizes consumer identity management by allowing your consumers to sign
up for your applications by using their social accounts, such as Facebook, Google, Amazon, or LinkedIn.
To start using Azure AD B2C, you need to create a new tenant by performing the following steps:
1. Sign in to the Azure classic portal with your tenant administrator account.
2. Click New, click App Services, click Active Directory, click Directory, and then click Custom Create.
3. On the Add Directory page, enter the name, domain name, and country or region for your tenant.
4. Select This is a B2C directory.
5. On the Add Directory page, click the confirmation check mark to complete the action.
Applications that are integrated with Azure AD B2C need to be registered in your B2C directory in the
Azure portal. During the registration process, each application gets a unique Application ID and Redirect
URI or Package Identifier. Currently B2C supports native apps, mobile apps, web apps, and web APIs that
are using the App Model v2.0 registration model. Application ID and Redirect URI are used by developers
to configure authentication for their applications.
To register an application in Azure AD B2C tenant, perform the following steps:
1. Sign in to the new Azure portal with the global administrative account for your new Azure AD B2C
tenant.
2. Find your tenant under the Directory tab, and click it.
3. On the B2C features blade, on the new Azure portal, click Applications.
4. Click +Add at the top of the blade.

5. Type the name of the application.
6. For mobile applications, toggle the Include native client switch to Yes. Copy the default Redirect
URI that is automatically created.
7. Click Create to register your application.
8. Click the application that you just created, and copy the globally unique Application ID that you will
use later in your code.
The next step in providing access for an application integrated with Azure AD B2C is to define the policies.
Policies define the consumer identity experiences such as sign up, sign in, or profile editing, and these
policies can be defined in the portal or by using a special query parameter in HTTP authentication
requests. For a sign-up policy, your applications can use identities from social accounts such as Google or
Facebook, or locally created accounts with email addresses, user names, and passwords. For the consumer
experience, you can combine different attributes, such as first name and postal code, and strengthen the
authentication process by implementing multi-factor authentication.
Demonstration: Managing Azure AD users, groups, and devices

• Create a new directory called Adatum.

• Create a new Global Administrator user account.
• Join a Windows 10–based computer to Azure AD.
Demonstration Steps
Create directories
to 20533C-MIA-CL1 as Student with the password Pa$$w0rd.
2. In Internet Explorer, go to the Azure classic portal, and then sign in by using the Microsoft account
that has administrative privileges to your subscription.
3. Add a directory by using the following settings:
o DIRECTORY: Create new directory
o NAME: Adatum
o DOMAIN NAME: Use your initials + the directory name + random numbers (e.g.
abcadatum123456)
o COUNTRY OR REGION: United States
Create a Global Administrator

1. Create the following user in the Adatum directory:
o USER NAME: kgruber
o FIRST NAME: Karen

o LAST NAME: Gruber
o DISPLAY NAME: Karen Gruber

o ROLE: Global Admin
o In the ALTERNATE EMAIL ADDRESS box, type the email address of your Azure subscription
o Enable Multi-Factor Authentication: Do not select
2. Note the new password.
3. Sign out of the portal.
4. Sign in as Karen Gruber, and change the temporary password to Pa$$w0rd123.
Join a Windows 10 device in Azure AD

1. Sign in to the Azure classic portal by using your Azure subscription.
2. Verify that the Adatum Azure AD tenant allows users to join their devices in Azure AD.
3. Click Settings, click Accounts, and then join MIA-CL1 into Azure AD by using the following
credentials:
o User name: kgruber@XXXadatumXXX.onmicrosoft.com
Note: Note that at this point, you would be able to sign in to the local computer by using
Azure AD credentials (in this case, you could use the newly created credentials
kgruber@XXXadatumXXX.onmicrosoft.com).
4. Verify that MIA-CL1 is shown in the Device tab of the Karen Gruber user account in the Adatum
Azure AD.
Question: Can you use Group Policy in Azure AD?
Question: What are the similarities between AD DS and Azure AD?

Lesson 2
Configuring application and resource access with
Azure AD
As the number of cloud-based applications increase, the challenges that administrators face also increase.
Administrators must ensure that they provide end users with secured access to these cloud-based
applications. They also should ensure that the users can access different applications without having to
remember many credentials.
Azure AD simplifies and secures the access to cloud-based applications by allowing you to enable SSO
and configure application access. You can extend the same features to LOB applications after you register
them in Azure AD. You can also implement RBAC, and monitor and control privileged identity
management.
Lesson Objectives
• Explain how to manage access to cloud applications.
• Explain how to integrate applications with Azure AD.
• Explain how to implement access to on-premises applications.
• Explain how to implement RBAC.
• Explain the purpose of Azure AD Privileged Identity Management.
Overview of managing cloud applications

SSO enables users to access SaaS applications,
such as Office 365, Salesforce, and so on, by using
a single Azure AD organizational account. This
means that administrators no longer need to
create and update separate user accounts for each
SaaS application. SaaS SSO also means that users
do not have to remember a separate password for
each SaaS application.
You can use several ways to deploy these

applications to end users, but the most common
scenario is to deploy by using the Application
Access Panel, which is a web-based portal that can
be accessed by using the following URL: https://myapps.microsoft.com.
Besides providing access to the applications, the Application Access Panel also allows users to edit their
profile settings, change their password, and provide information needed for password reset settings. They
can also edit multi-factor authentication settings and view details such as their user ID, alternative email,
and other phone numbers.
The Application Access Panel requires authentication from an organizational account in Azure AD, or if
the federation has been enabled, authentication can use AD DS. After users are authenticated, they have
access to the applications that have been integrated with the Azure AD.
The Application Access Panel is supported on Internet Explorer 8 and newer, Chrome, and Firefox, and can
also be used on browsers that support JavaScript and CSS. The portal does require an Access Panel
extension for the appropriate browser, and that can be installed the first time when the user accesses an
application that has been configured for password-based SSO.
Access to applications can be granted to users or groups from Azure AD. You can assign access to
applications that have been already pre-integrated in the gallery or custom applications that have been
developed to support SAML 2.0 as federated apps, or that have an HTML-based sign-in page with a
password SSO.
To identify the most used cloud-based applications, you can use the Cloud App Discovery tool. This tool
can provide you with information about how the cloud apps are being used, based on number of users,
number of web requests, and the time spent working with the apps. Data collected from the Cloud App
Discovery tool enables identifying the applications, so the IT department can simplify access by providing
SSO with Azure AD. The Cloud App Discovery tool uses agents that are installed on users' computers, and
the agents monitor each time that a cloud-based application has been accessed. Collected data is then
sent using an encrypted channel to the Cloud App Discovery service, which you can use to generate
reports and statistical information. You can deploy Cloud App Discovery agents by using Group Policy
deployment, or Microsoft System Center Configuration Manager.
Access to Cloud App Discovery-based inventory is only available in the Premium edition of Azure AD for
the users with global administrative rights or delegated users. To implement Cloud App Discovery, first
sign in to the Azure portal, and then locate it in the Azure Marketplace.
Integrating applications with Azure AD
Azure AD gallery applications

Azure AD gallery applications provide automatic
support for Azure AD. Therefore, the
administrators do not need to provision user
accounts manually for these applications.
Examples of gallery applications include Office
365, Dropbox for Business, and Salesforce.
You can access the Azure AD application gallery from: https://azure.microsoft.com/en-us

/marketplace/active-directory/.
You can add and manage SSO for the applications by using the Application page in Azure AD. More than
2,500 SaaS applications are integrated with Azure AD for authentication and authorization.
To add an application from the gallery, perform the following steps:

1. Sign in to the portal with an account that has global administrative privileges.
2. Navigate to the Active Directory node, and select either default directory or any custom directory.
3. On the Application page, click Add an application from the gallery, and then select the
application whose access you plan to manage.
4. You can then assign access to individual users or Azure AD groups.
5. You can also configure either password-based SSO or federated SSO.
Federation-based SSO
Federation-based SSO requires that users authenticate to Azure AD by using their organizational account
credentials to access an application. With a federated trust, a SaaS application redirects users to sign in by
using an application protocol, such as SAML 2.0, WS-Federation, or OpenID Connect, from your Azure AD.
Trust relationships are established by using signing certificates. You need to upload these certificates to
the third-party SaaS application. After they are uploaded, they will be used to validate authentication
tokens issued by Azure AD.
Federated applications support automatic user provisioning from within the Azure portal. To enable
automatic provisioning, you need to sign in to the third-party application by using administrative
credentials, and then grant permission to Azure AD for provisioning user accounts in the application.
Password-based SSO
With password-based SSO, access to a third-party SaaS application is established by providing the user
name and password for the application. After the credentials are entered in the Access Panel, the
credentials are encrypted and securely stored in Azure AD. Most HTML forms-based sign-in applications
can be configured to use password-based SSO by administrators who can manage the credentials on
behalf of the user, or by users who can enter their credentials when they access the application.
Adding line-of-business applications

Organizations that develop their own line-of-business (LOB) applications can protect access to those
applications by using Azure AD. Developers can enable their own custom applications to use Azure AD,
and obtain the same features that are available in the Azure AD gallery applications.
To add an LOB application, perform the following steps:
1. Sign in to the Azure portal with the account that has global administrative privileges.
3. On the Application page, click Add an application my organization is developing.
4. Type the name, and select whether the application is a web application or a native client application.
5. Provide the application’s sign-on URL and the application ID URI.
Note: Sign-on URL takes the users to a page where they can sign in and use the
application. The application ID URI is used as a unique logical identifier for the application.
Adding and registering the application in Azure AD is the first step in managing access to the application.
After you do this, you also need to coordinate with the developers and IT professionals, and ensure that
the owners of the application can use the sign-on URL and application ID URI to develop and configure
the application. You can find the application ID URI in the single sign-on section that is within the
configure tab of the LOB application. In this section, you can also locate the replay URL, which is the
physical address for the application to which Azure AD will send SAML authentication tokens for
authenticated users.
Adding SaaS applications that are not listed in the gallery

Even if a SaaS application is not pre-integrated with the app gallery, you can still integrate it with
provisioned users if the SaaS application supports Azure AD authentication protocols or if the application
has an HTML-based sign-in page with a password SSO.
For SaaS applications that support SAML 2.0, WS-Federation, or OpenID Connect, authentication with
Azure AD is established by using a signing certificate that is generated in the Azure AD directory. For SaaS
applications that support HTML-based sign-in page, authentication is enabled by using password-based
SSO.
To add a SaaS application that is not listed in the gallery, perform the following steps:
1. Sign in to the Azure portal with the account that has global administrative privilege.
2. Navigate to the Active Directory node and select either default directory or any custom directory.
3. On the Application page, click Add an application from the gallery.
4. On the Application Gallery page, click Custom.
5. Select Add an unlisted application my organization is using, and in the name text box, type the
name of the application.
After the application is added to the Azure AD gallery, you can configure SSO for the application by using
any of the previously described methods. For SAML 2.0–based applications, authentication is established
by using the Windows Azure AD Single Sign-On option that requires you to configure the following
settings:
• Sign on URL. Provide the web-based sign-in page for this application.
• Identifier. Provide a unique identifier for the application for which SSO is being set up.
• Replay URL. Provide the URL where the application expects to receive the authentication token.
Based on this information, Azure AD will generate a certificate and the following three URLs that need to
be configured with the SaaS application:
• Issuer URL. This is the value that appears as the Issuer inside the SAML token issued to the
application.
• Single Sign-On Service URL. This is the endpoint that is used for sign-in request.
• Single Sign-Out Service URL. This is the endpoint that is used for sign-out request.
The final step is to start assigning users and groups to the custom SaaS application by using the same
procedure described earlier.
Implementing access to on-premises applications

The Azure AD Application Proxy is a cloud-based
proxy service that enables an organization's own
custom browser-based applications (such as
SharePoint sites, Outlook Web Access, and IIS-
based applications) to use Azure AD. The Azure
AD Application Proxy is a reverse-proxy service
that supports browser-based applications, using
both unsecure (http:) and secure (https:)
connections. Users can sign in to LOB apps from
home on their own devices and authenticate
through this cloud-based proxy.
To use the Azure AD Application Proxy, you must

install a simple software agent, or connector, on an on-premises server, such as a back-end application
tier. The connector manages an outbound connection from within your network to the cloud-based Azure
proxy service.
The process that explains how the Azure AD Application Proxy service works is described below:
1. The user tries to access the application from the device located outside the company premises by
opening a web browser.
2. The application proxy redirects the user sign-in to the Azure AD sign-in page for authentication.
3. The user gets the token from Azure AD and presents it to the application proxy, which retrieves the
user principal name (UPN) and security principal name (SPN).
4. The connector that is installed in the internal network requests a Kerberos ticket on behalf of the user
from AD DS.
5. The Kerberos ticket is received from AD DS.

6. The connector presents that ticket to the application by using Kerberos Constrained Delegation.
7. The application verifies the access, and responds to the client request through the application proxy.
The connector can be installed on the application server itself, or on any server with Internet connectivity
that has also access to a web application, without complex requirements for specific network design. If
there is a firewall between the server hosting the connector and the Internet, be sure that the firewall
allows outbound requests to pass from the connector to the application proxy.
The application proxy in Azure AD is a feature that requires either basic or premium Azure AD. You
can enable application proxy on the Configure menu of the Azure AD directory by setting Enable
Application Proxy Services for this Directory to Enabled. After that, you can download and install the
connector with the administrative Global Administrator privilege for your organization. This installs two
Windows services, Microsoft AAD Application Proxy Connector and Microsoft AAD Application
Connector Proxy Connector Updater.
To publish an internal application, and to make this publicly accessible for the users outside your private
network, perform the following steps:
1. Sign in to the portal with an account that has the global administrative privilege.
3. On the Application page, click Publish the application that will be accessible from outside your
network.
4. Verify the external URL, which is automatically created with the suffix msappproxy.net.
5. Set the preauthentication method to either Azure AD or pass-through.
6. Provide an internal URL that the application proxy connector can use to access the application
internally.
Implementing RBAC
RBAC enables fine-grained access management
for resources that exist in Azure. The service allows
organizations to set up access to Azure resources
based on permissions and privileges that can be
granted to users, groups, and other applications
from Azure AD. By using RBAC, you can enable
self-service management of cloud resources for a
certain administrative team, while retaining
central control over security sensitive
infrastructure. For example, you can allow your
development team to create their own virtual
machines, but limit the networks where those
machines can be connected.
RBAC built-in roles

RBAC has three basic roles that apply to all resource types:
• Owner. This role has full access to all the resources and can delegate access to others.
• Contributor. This role can create and manage all types of resources, but can’t grant access to other
users and groups.
• Reader. This role can view existing Azure resources.
Different resource types allow usage of specific built-in RBAC roles with predefined permissions that
further narrow access to resources. Examples of built-in roles include virtual machine contributor or SQL
database contributor.
Additional Reading: For the list of built-in roles, go to: http://aka.ms/Cge87w.
RBAC is supported by the Azure portal and Azure Resource Manager APIs. Permissions granted through
RBAC are inherited from parent scopes down to child scopes, based on the hierarchy model of
subscription, resource group, and resource. The Owner role at the subscription scope has equivalent
permissions of the classic subscription administrator and has full access to the Azure subscription. Azure
RBAC is limited to granting permissions at the management level, such as creating a SQL database, but it
cannot be used for data operations such as creating a table within a SQL database.
If predefined built-in roles do not meet your expectations, you can create custom roles by using
PowerShell or Azure CLI. You can assign these roles to users, groups, and applications at different scopes
for subscriptions, resource groups, and individual resources.
Managing RBAC by using the Azure portal

You can configure RBAC by using the Azure portal. However, Azure AD users who are granted permissions
through the RBAC security model cannot use the Azure classic portal for any management activities.
To manage RBAC by using the Azure portal, perform the following steps:
1. In the Azure portal, locate the Users blade for the resource for which you plan to manage RBAC.
2. Click the Add icon on the Users blade.
3. Select the role that you want to assign.
4. Search for and select the user, group, or application to which you want to grant access. You can
search the directory for users, groups, and applications by using display names, email addresses, and
object identifiers.
5. Click OK to confirm the selection.
You can remove the permission by using a similar procedure, but you cannot remove inherited
permissions at child scopes.
Manage RBAC by using Azure PowerShell

You can manage RBAC by using the Azure Resource Manager mode of Azure PowerShell. For this, you
need to have Windows PowerShell version 3.0 or newer, and Azure PowerShell version 0.8.8 or newer.
Azure PowerShell provides the following cmdlets to manage role assignments:

• Get-AzureRoleAssignment. Retrieves the roles assigned to a user.
• Get-AzureRoleDefinition. Lists the definition for a role.
• New-AzureRoleAssignment. Assigns a role assignment to a user or a group.
• Remove-AzureRoleAssignment. Removes a role assignment from a user or a group.
For example, the following command adds a user to the Reader role at the specified scope:
New-AzureRoleAssignment -UserPrincipalName user@somedomain.com -RoleDefinitionName Reader

-Scope /subscriptions/GUID/resourceGroups/ResourceGroupName
Policy definitions
You can use Azure Resource Manager policy definitions to restrict access to a particular resource type in
Azure. When a user is authenticated through RBAC and receives some predefined access, a policy
definition can prevent or allow that access to specific type of resources or restrict the locations in which
the resource can be provisioned. These definitions contain conditions or logical operators that define the
action such as deny or audit, and you can apply them to a subscription, a resource group, or individual
resources.
Azure AD Privileged Identity Management

You can use Azure AD Privileged Identity
Management to control and monitor privileged
identities and their access to resources that exist
in the cloud. Azure AD Privileged Identity
Management allows you to grant on-demand
administrative access, which minimizes the
security risk of granting permanent access to
resources in Azure or Office 365. Temporary
administrators need to complete the activation
process for the assigned role to become active.
The process of role activation includes providing
information about the duration of the role and
the information that the user needs to provide during role assignment. Additionally, you can use Azure
AD Privileged Identity Management to discover the users who have administrative roles, get alerts on the
usage of privilege roles, and generate reports for administrative access.
You can enable Privileged Identity Management in the Azure portal by using an account that is a Global
Administrator for the directory. After you enable Privileged Identity Management, you can use the
privileged identity management dashboard to monitor the number of users that are assigned privileged
roles, and the number of temporary or permanent administrators.
Demonstration: Integrating SaaS apps with Azure AD and configuring

RBAC
• Add a directory application and configure SSO.
• Implement RBAC.
Demonstration Steps
Add a directory application and configure SSO
1. In the Adatum directory, create the following application from the gallery:
o Microsoft Account (Windows Live)
2. Verify that Configure single sign-on is enabled by default.
3. Assign the application to the following user:
o Karen Gruber
4. Select the option to enter Microsoft Account (Windows Live) credentials on behalf of the user.
5. In the Email Address text box, type the email address of your Azure subscription. In the Password
text box, type your Azure subscription password, and then click the check mark.
Implementing RBAC
1. Sign in to the Azure classic portal by using your subscription account.
2. Create the following user in the Default directory:
o USER NAME: rdesforges
o FIRST NAME: Remi
o LAST NAME: Desforges
o DISPLAY NAME: Remi Desforges
o ROLE: User
4. Switch to the Azure portal.

5. In the Navigation pane, select Subscriptions.
6. In the Subscription blade, select your Azure Pass subscription.
7. In the Azure Pass blade, scroll down to the Access section, and then click the Reader role.
8. In the Reader Azure Pass blade, click Add.
9. In the Add Users blade, in the Users text box, type the name of the Remi Desforges user, which is
created in the previous task.
o rdesforges@yourdomain.onmicrosoft.com
10. Click the user, and then click Select.
11. Verify that Remi is added as a reader to your Azure subscription.
Question: How can you centrally manage identities, and access to applications and resources
in the cloud?
Lesson 3
Overview of Azure AD Premium
Features, such as password write-back or group self-service management, increase overall user
productivity and reduce administrative overhead for enterprises. These features and other advanced
features such as increased auditing and reporting and advanced multi-factor authentication are available
only in the Azure AD Premium edition.
Lesson Objectives
• Identify the features of Azure AD Premium.
• Describe the purpose of Azure Multi-Factor Authentication.
• Explain how to configure advanced Azure Multi-Factor Authentication settings.
Introducing Azure AD Premium

The Azure AD Premium edition provides
additional functionality beyond the Free and Basic
editions. However, this edition requires additional
cost per user provisioning. You can procure it as
an additional license or as a part of the Microsoft
Enterprise Mobility Suite, which also includes the
license for Azure Active Directory Rights
Management Services and Microsoft Intune.
Microsoft provides a free trial period of 90 days

that covers 100 user licenses that can be used to
experience the full functionality of the Azure AD
Premium edition.
The following features are available with the Azure AD Premium edition:
• Self-service group management. It simplifies the administration of groups where users are given the
rights to create and manage the groups. End users can create requests to join other groups, and
groups' owners can approve requests and maintain their groups’ memberships.
• Advanced security reports and alerts. You can monitor and protect access to your cloud applications
by viewing detailed logs that show advanced anomalies and inconsistent access pattern reports.
Advanced reports are machine learning based and can help you gain new insights to improve access
security and respond to potential threats.
• Multi-Factor Authentication. Full Multi-Factor Authentication works with on-premises applications

(using VPN, RADIUS, and others), Azure, Office 365, Dynamics CRM Online, and third-party Azure AD
gallery applications. It does not work with non-browser off-the-shelf apps, such as Microsoft Outlook.
Full Multi-Factor Authentication is covered in more detail in the following topics in this lesson.
• Microsoft Identity Manager (MIM) licensing. MIM integrates with Azure AD Premium to provide
hybrid identity solutions. MIM can seamlessly bridge multiple on-premises authentication stores such
as AD DS, LDAP, Oracle, and other applications with Azure AD. This provides consistent experiences to
on-premises LOB applications and SaaS solutions.
• Enterprise SLA of 99.9%. You are guaranteed at least 99.9% availability of the Azure AD Premium
service. The same SLA applies to Azure AD Basic.
• Password reset with writeback. Self-service password reset follows the Active Directory on-premises
password policy.
• Cloud App Discovery. This tool discovers the most frequently used cloud-based applications.
• Azure AD Connect Health. You can use this tool to gain operational insight into Azure AD. It works
with alerts, performance counters, usage patterns, and configuration settings, and presents the
collected information in the Azure AD Connect Health portal.
Azure Multi-Factor Authentication

Azure Multi-Factor Authentication adds an
additional security layer in the authentication
process by requiring more than one method of
authentication to identify user identity. User
names and passwords are still required to sign in
to your data and applications, but an additional
access method can be added as a second factor of
authentication. Multi-factor authentication
combines something that you know, such as a
password or a PIN, with something that you have,
such as your phone or a token, and/or something
that you are (biometric technologies).
You can implement Azure Multi-Factor Authentication in different ways based on users’ demands and the
level of additional security that they need. The following are some ways to implement multi-factor
authentication:
• You can use the mobile app as a software token to provide one-time passwords or to receive push
notifications from the application.
• You can authenticate by using a phone call.
• You can authenticate by using text messages, which is very similar to mobile app authentication, but
the push notifications or the codes will come via text messages.
• You can use third-party OAuth tokens.
Azure Multi-Factor Authentication is used in different ways:
• Multi-Factor Authentication Provider. It is required to extend the multi-factor authentication

functionality to all users and to generate additional reports or custom greetings.
• Multi-factor authentication is included in Azure AD Premium. There is no need to create a security

provider. You only need to start assigning users.
• Free of charge for administrators. Every administrative account of an Azure subscription can be
protected with multi-factor authentication.
• A subset of the Azure Multi-Factor Authentication functionality is included in Office 365. Multi-factor
authentication for Office 365 does not require additional cost besides an Office 365 subscription
license. However, this works only with Office 365 applications.
Choosing a multi-factor security solution

Organizations can choose different types of multi-factor authentication implementations depending on
their needs. Before you choose the optimal multi-factor authentication solution, it is very important to
carefully evaluate the solution. The basic determination process when deciding which multi-factor
authentication solution to deploy is to know what you want to secure and where the Active Directory
users are located (on-premises or in the cloud). Based on these findings, you can use:
• Multi-factor authentication in the cloud. This is used mostly if the users’ accounts are located in Azure
AD and the main goal is to secure access to first-party Microsoft apps, SaaS apps from application
gallery, and applications published through Azure AD Application Proxy.
• Multi-factor authentication on-premises. For the users located on AD DS or users federated with
Azure AD by using AD FS, you need to install the Multi-Factor Authentication server and set up with
on-premises Active Directory. You can use multi-factor authentication on-premises for the same
scenarios as multi-factor authentication in the cloud. Additionally, you can use multi-factor
authentication on-premises for on-premises applications and remote access scenarios where VPN
and/or Remote Desktop Gateway are used. If you are deploying the Remote Desktop Gateway and
the Azure Multi-Factor Authentication server by using RADIUS, the Azure Multi-Factor Authentication
server is configured as a RADIUS proxy between the Remote Desktop Gateway and Network Policy
Server (NPS).
Technical scenarios for Azure Multi-Factor Authentication

There are several scenarios for deploying Azure Multi-Factor Authentication:
• Multi-factor authentication for Office 365.
• Azure Multi-Factor Authentication options for federated users.
• Remote Desktop Gateway and Azure Multi-Factor Authentication Server using RADIUS.
• Using Azure Multi-Factor Authentication with AD FS.
Multi-factor authentication for Office 365

You can manage Office 365 Multi-Factor Authentication by using the Office 365 portal. Office 365 users
will experience the same functionality and features as those that are provided for free to all Azure
administrators. These features are:
• The ability to enable and enforce multi-factor authentication for end users.
• The use of a text message, a call to an office phone, or a mobile phone app as a second
authentication factor.
• App passwords for non-browser clients, such as Microsoft Outlook.
• Default voice messages during authentication phone calls.
If you add the Office 365 directory to your subscription, you can manage multi-factor authentication for
Office 365 users by using the Azure portal.
To set up multi-factor authentication for Office 365, perform the following steps:
1. Sign in with your credentials to Office 365 admin center.
2. Click users and groups, and then click Active Users.
3. To set multi-factor authentication requirements, click Set up.
4. Search and select the users for whom you want to enable multi-factor Authentication.
5. Select Enable multi-factor authentication.

Azure Multi-Factor Authentication options for federated users

In scenarios where you have a hybrid solution incorporating AD DS and Azure AD using AD FS, there are
two possible solutions for using multi-factor authentication:
• Securing cloud resources by using Azure Multi-Factor Authentication or AD FS.
• Secure cloud and on-premises resources by using the Azure Multi-Factor Authentication server.
Authentication experience is different for browser-based applications that are using Azure Multi-Factor
Authentication, when compared to nonbrowser-based apps where the first factor of authentication is
performed on-premises by using AD FS and the second factor is performed on-premises by honoring the
claim.
Remote Desktop Gateway and Azure Multi-Factor Authentication Server by using

RADIUS
If you deploy the Remote Desktop Gateway and Azure Multi-Factor Authentication server by using the
RADIUS protocol, the Azure Multi-Factor Authentication server is configured as a RADIUS proxy between
the Remote Desktop Gateway and Network Policy Server (NPS). You install the Multi-Factor
Authentication server on a domain-joined computer, and configure it for RADIUS authentication with the
server address that points to NPS. You also need to configure NPS to receive RADIUS authentication back
from Azure Multi-Authentication server by configuring the clients and a shared secret.
Using Azure Multi-Factor Authentication with AD FS

This scenario is useful if your organization is federated with Azure AD and some of the resources exist
both in the cloud and on-premises.
To install the Azure Multi-Factor Authentication server locally on the same server as AD FS, perform the
following steps:
1. Download and install Azure Multi-Factor Authentication server.
2. In the Azure Multi-Factor Authentication user interface, select Allow user enrollment and Allow
users to select method, and then select Multi-Factor Authentication.
3. Click the check mark to install the AD FS adapter.

4. In the AD FS Adapter window, click Next, and then accept to create the PhoneFactor admins group
and to add current administrator to that group.
5. Proceed with the installation by accepting the default values.

6. Proceed with the registration of the adapter with AD FS by opening Windows PowerShell and
executing the following script:
C:\Program Files\Multi-Factor Authentication Server\Register-

MultiFactorAuthenticationAdfsAdapter.ps1
7. Edit the Global Authentication Policy in AD FS to use the newly registered adapter.
Configuring advanced Multi-Factor Authentication settings

Some specific settings provide more control
on how you can implement Multi-Factor
Authentication in various scenarios. These settings
are explained in the following sections.
Fraud Alert
The Fraud Alert feature enables users to report
fraudulent attempts to sign in to their Azure
resources. If a user receives an unexpected multi-
factor authentication request, simply ignoring the
request will deny access to anyone who attempts
to authenticate. However, by using the Fraud Alert
feature, the user can respond to the request and
enter the fraud alert code (0# by default) to report the attempted access. Using fraud alert denies the
authentication request, and also blocks the user's account, so that additional authentication attempts are
automatically denied. Email notifications can also be sent to administrators, or others such as security
teams. After appropriate action has been taken, including changing the user's password, an administrator
can then unblock the user's account by using the Multi-Factor Authentication Management Portal.
One-Time Bypass
One-Time Bypass is a temporary setting to enable a user to sign in without using Multi-Factor
Authentication. The bypass expires after the specified number of seconds. This can be useful if a user
needs to use an Azure-hosted application, but is not able to access a phone for text messaging or
automated calls, or the Multi-Factor Authentication app. The default one-time bypass period is five
minutes.
Custom Voice Messages

Custom Voice Messages enable administrators to customize the messages that are used when Multi-
Factor Authentication is conducted through automated voice calls to an office phone. This means that
you could record your own voice phrases to replace the standard clips that are supplied with Multi-Factor
Authentication.
Trusted IPs
IP whitelisting, or Trusted IP addresses, enables administrators to bypass Multi-Factor Authentication for
users who sign in from the company’s local intranet. For managed tenants, this is achieved through
specific IP address ranges and for federated tenants by using AD FS.
App Passwords
App Passwords permit users that have been enabled for multi-factor authentication to use non-browser
clients, such as Outlook 2013 with Office 365. App passwords are created within the Azure portal, and
enable the user to bypass Multi-Factor Authentication for that application.
Caching
The Caching feature allows users to suspend using Multi-Factor Authentication for a defined period of
time after they have been authenticated by using Multi-Factor Authentication.
Suspend Multi-Factor Authentication

For remembered devices and browsers, users have an option to suspend Multi-Factor Authentication for a
period of time. The default value is 14 days and the maximum is 60 days. Users have to use Multi-Factor
Authentication after the time threshold is reached.
In addition to the above settings, there are some specific user settings for Multi-Factor Authentication
that might improve security in case of a stolen or lost device. These settings are explained in the following
sections:
Require selected users to provide contact methods again

This setting will require users to provide the additional method of verification again if the previous
settings suspend or cache Multi-Factor Authentication. The existing password for a specific application will
not change.
Delete users existing password

This setting will require creation of a new password for nonbrowser applications.
Restore Multi-Factor Authentication on all suspended devices for a user

In case a user finds a lost device, this setting can reset Multi-Factor Authentication and remove the
suspension from all the user’s devices and browsers.
Demonstration: Configuring and using Azure AD Premium Multi-Factor

Authentication
• Create a Multi-Factor Authentication provider.
• Configure fraud alerts.
• View fraud alert reports.
• Configure one-time bypass settings.
• Create a one-time bypass.
• Configure voice messages.
• Configure trusted IP addresses.
• Enable users to create app passwords.
Demonstration Steps
Connect to the Azure classic portal

• Start Internet Explorer, browse to https://manage.windowsazure.com, and sign in by using the
Create a multi-factor authentication provider

1. In the navigation pane, scroll down, and then click ACTIVE DIRECTORY.
2. Click MULTI-FACTOR AUTH PROVIDERS, and then create a new Multi-Factor Authentication
provider with the name Adatum-MFA.
3. Ensure that Per Enabled User is selected in the USAGE MODEL drop-down menu, and then link the
Multi-Factor Authentication provider to the Adatum directory.
4. Click CREATE.
Configure fraud alerts

1. Click MANAGE at the bottom of the page to open the Azure Multi-Factor Authentication
management portal.
2. Click Settings, and then in the Fraud Alert section, verify the following:
o Allow users to submit Fraud Alerts is enabled by default.
o Block user when fraud is reported is also enabled by default.
3. In the Code To Report Fraud During Initial Greeting text box, type 999.
4. In the Send fraud alert notifications to these email addresses text box, type the email address of
the Microsoft account that is the Service Administrator or a Co-Administrator of your Azure
subscription.
5. At the bottom of the page, click Save.
View fraud alert reports

1. In the Azure Multi-Factor Authentication management portal, on the left side of the page, under
VIEW A REPORT, click Fraud Alert.
2. Specify a date range for the report, specify user names, phone numbers, and user status, and then
click Run.
Configure one-time bypass settings

1. In the Azure Multi-Factor Authentication management portal, click Settings, and configure one-time
bypass for a period of 300 seconds.
2. In the Send one-time bypass used notifications to these email addresses text box, type the email
address of the Microsoft account that is the Service Administrator or a Co-Administrator of your
Azure subscription, and then click Save.
Create a one-time bypass

1. In the Azure Multi-Factor Authentication management portal, under USER ADMINISTRATION, click
One-Time Bypass, and then click New One-Time Bypass.
2. In the Username text box, type kgruber@XXXadatumXXX.onmicrosoft.com (where

XXXadatumXXX is your unique Adatum directory name).
3. In the Bypass Reason text box, type Lost phone, and click Bypass.
Configure voice messages

1. In the Azure Multi-Factor Authentication management portal, in the CONFIGURE section, click Voice
Messages, and then click New Voice Message.
2. Click Manage Sound Files, click Upload Sound File, browse to C:\Windows\Media, and then select
Widows Message Nudge.wav to upload.
3. In the CONFIGURE section, click Voice Messages, and then click New Voice Message.
4. In the Language list, select en-US: English (United States).

5. Leave the Application text box empty. In the Message Type box, select Greeting (Standard).
6. In the Sound File box, select Widows Message Nudge.wav - MFA voice message, and then click
Create.
Configure trusted IPs

1. Under active directory, click DIRECTORY, select Adatum, and then click CONFIGURE.
2. In the Multi-Factor Authentication section, click Manage service settings.
3. If you get a Sign in page, enter the following credentials, and then click Sign in:
o User name: the Microsoft account that is the Service Administrator or a Co-Administrator
of your Azure subscription
o Password: your Azure subscription password
4. On the service settings page, under trusted ips, select Skip multi-factor authentication for
requests from federated users on my intranet, and then click save.
Enable users to create app passwords

1. At the top of the service settings page, ensure that Allow users to create app passwords to sign
in to non-browser apps is selected.

Reset-Azure
subscription.
The script will take a few minutes to reset your Azure environment and prepare it for the next lab.
The script removes all storage, virtual machines, virtual networks, cloud services, and resource groups. The
script does not remove the Azure AD directory. You can delete it manually, or you can leave it as is
because it does not affect subsequent labs.
Question: What are the main benefits of Azure AD Premium?
Question: A. Datum requires that their applications use multi-factor authentication. The
company has implemented this technology in its on-premises infrastructure, and wants to
extend it for applications and resources that reside in Azure. A. Datum wants to use the
authentication methods that are similar to what they are currently using in the on-premises
infrastructure. Can they use Azure Multi-Factor Authentication for this, and if so, why?
Lab: Implementing Azure AD

Scenario
The IT department at A. Datum Corporation currently uses AD DS, and a range of Active Directory-aware
applications. While preparing for synchronizing its AD DS to Azure AD, A. Datum wants you to test some
of the features of Azure AD. The company wants you to control access to third-party SaaS apps by using
Azure AD users and groups. A. Datum also wants you to configure SSO to these apps and protect them by
using Multi-Factor Authentication.
In addition to these tasks, A. Datum wants you to evaluate some of the advanced features Azure AD
Premium offers. Additionally, it wants you join a Windows 10–based computer to an Azure AD tenant to
test the Azure AD functionality and prepare for implementing this configuration on all the Windows 10–
based computers in the Research department.
Objectives
• Administer Azure AD.
• Configure SSO for Azure AD gallery applications.
• Configure multi-factor authentication for administrators.

• Use the advanced features offered by Azure AD Premium.
• Configure SSO from a Windows 10–based computer that is joined to Azure AD.
Lab Setup
User name: Student
Password: Pa$$w0rd
Before you start this lab, ensure that you complete the tasks in the Preparing the environment
demonstration, which is in the first lesson of this module. Also ensure that the setup script is complete.
Exercise 1: Administering Active AD

Scenario
You want to test the functionality of Azure AD by first creating a new Azure directory and enabling the
Premium functionality. You then want to create some pilot users and groups in Azure AD. You plan to use
both the portal and Microsoft Azure Active Directory Module for Windows PowerShell.
1. Create directories.
2. Activate Azure AD Premium trial.
3. Manage users by using the Azure portal.
4. Manage groups by using the Azure portal.
5. Manage users and groups by using Azure PowerShell.

 Task 1: Create directories

to 20533C-MIA-CL1 as Student with the password Pa$$w0rd.
2. In Internet Explorer, browse to http://manage.windowsazure.com, and then sign in to the portal by

using the Microsoft account that is associated with your Azure subscription.
3. Add a directory by using the following settings:
o NAME: Adatum
o DOMAIN NAME: Use your initials + the directory name + random numbers (e.g.
abcadatum123456)
 Task 2: Activate Azure AD Premium trial

1. In the navigation pane, select the Adatum directory.
2. In the Licenses tab, enable Azure AD Premium trial feature.
 Task 3: Manage users by using the Azure portal

1. Create a user in the Adatum directory by using the following settings:

o FIRST NAME: Remi

o ROLE: User

3. Create another user in the Adatum directory by using the following settings:
o FIRST NAME: Karen
o LAST NAME: Gruber
o In the ALTERNATE EMAIL ADDRESS box, type the email address of the Microsoft account that is
the Service Administrator or a Co-Administrator of your Azure subscription
5. Sign out of the portal.
6. Sign in as Karen Gruber, and then change the temporary password to Pa$$w0rd123.
 Task 4: Manage groups by using the Azure portal

1. Browse to https://manage.windowsazure.com, and sign in by using the Microsoft account that is
associated with your Azure subscription.
2. Select the Adatum directory, and then click Configure.
3. Enable Delegated Group Management Enabled.
4. Create the following group in the Adatum directory:

o NAME: Sales
o DESCRIPTION: Sales team
5. Add Remi Desforges to the Sales group.
o NAME: Marketing
o DESCRIPTION: Marketing employees

7. Add Remi Desforges to the Marketing group.
o NAME: Sales and Marketing

o DESCRIPTION: Sales and Marketing employees
9. Add the Sales and Marketing groups to the Sales and Marketing group.
 Task 5: Manage users and groups by using Azure PowerShell

1. Start Windows PowerShell ISE as an administrator.
2. Open D:\Labfiles\Lab09\Starter\ExampleCommands.ps1.
3. In the PowerShell ISE, in the command prompt pane, enter the following command, and then press
Enter:
Connect-MsolService
4. Sign in as Karen Gruber.
5. In the PowerShell ISE, in the script pane, locate the following code:
New-MsolUser -UserPrincipalName mledford@<#Copy your Azure Directory name

here#>.onmicrosoft.com -DisplayName “Mario Ledford” -FirstName “Mario” -LastName
“Ledford” -Password ‘Pa$$w0rd123’ -ForceChangePassword $false -UsageLocation “US”
6. Replace <#Copy your Azure Directory name here#> with your Azure AD directory name. In the
Windows PowerShell ISE, in the script pane, select the code that you just edited. On the toolbar, click
the Run Selection button and wait for the script to complete.
Enter to list all the users:
Get-MsolUser
8. Create a new group by running the following command:
New-MsolGroup -DisplayName “Azure team” -Description “Adatum Azure team users”

Enter to list all the groups:
Get-MsolGroup
10. In the PowerShell ISE, in the script pane, locate the following code, and then select it:
$group = Get-MsolGroup | Where-Object {$_.DisplayName -eq "Azure team"}
11. On the toolbar, click the Run Selection button and wait for the script to complete.
12. In the PowerShell ISE, in the Script pane, locate the following code and select it:
$user = Get-MsolUser | Where-Object {$_.DisplayName -eq "Mario Ledford"}
13. On the toolbar, click the Run Selection button, and wait for the script to complete.
14. In the PowerShell ISE, in the Script pane, locate the following code and select it:
Add-MsolGroupMember -GroupObjectId $group.ObjectId -GroupMemberType "User" -

GroupMemberObjectId $user.ObjectId
16. In the PowerShell ISE, in the script pane, locate the following code and select it:
Get-MsolGroupMember -GroupObjectId $group.ObjectId
18. Switch to Internet Explorer.
19. Click USERS, and verify that Mario Ledford appears in the list of users.
20. Click GROUPS, and verify that Azure team appears in the list of groups.
Results: After completing this exercise, you should have created some pilot users and groups in
Azure AD by using the Azure portal and Microsoft Azure Active Directory Module for Windows
PowerShell. You will also enable the Azure AD Premium functionality.
Exercise 2: Configuring SSO

Scenario
Because A. Datum is planning to deploy cloud-based applications, and requires users to use SSO for these
applications, you now want to install and configure a test application, and then validate the SSO
experience.
1. Add directory applications and configure SSO.
2. Test SSO.
 Task 1: Add directory applications and configure SSO

o Microsoft Account (Windows Live)
o Mario Ledford
4. Select the option that allows you to enter the Microsoft account credentials on behalf of the user.
5. In the Email Address box, type the email address of the Microsoft account associated with your
Azure subscription. In the Password box, type the corresponding password, and then click the check
mark.
o Skype
o Mario Ledford
9. In the Assign User dialog box, do not enter the Microsoft Account credentials on behalf of the user.
 Task 2: Test SSO

1. Go to https://account.activedirectory.windowsazure.com/applications, and sign in by using the
following credentials (where XXXadatumXXX is your unique Adatum domain name):
o User name: mledford@XXXadatumXXX.onmicrosoft.com
2. On the applications page, note the options to update the credentials and report a problem about
the Microsoft account.
3. Run the Microsoft Account application, and complete the Access Panel Extension Setup Wizard.

5. Click Microsoft Account, enter the credentials for your subscription account, and verify that your
sign-in to the Access Panel has automatically signed you in to your Microsoft account.
Note: If you are prompted to sign in again, use the credentials for your subscription
account.
6. Click Skype, and then verify that you are prompted for credentials. This happens because you did not
enter any credentials on behalf of the user when you configured SSO.
Results: After completing this exercise, you should have installed and configured a test application and
validated the SSO experience.
Exercise 3: Configuring Multi-Factor Authentication

Scenario
Because A. Datum requires applications to use Multi-Factor Authentication, you now want to configure
and test Multi-Factor Authentication for Global Administrators.
1. Configure Multi-Factor Authentication.
2. Test Multi-Factor Authentication.
 Task 1: Configure Multi-Factor Authentication

1. Sign in to the Azure portal by using your Azure subscription.
2. Configure the Adatum directory to enable Multi-Factor Authentication for Karen Gruber.
 Task 2: Test Multi-Factor Authentication

Note the following message: Your admin has required that you set up this account for additional
security verification.
2. Click Set it up now.

On the additional security verification page, note the contact method options.
3. Optional step: If you have access to a mobile phone in the classroom, and have a signal or data
connection, you can complete the additional security verification steps on the additional security
verification page.
Results: After completing this exercise, you should have configured Multi-Factor Authentication for
administrators.
Exercise 4: Configuring SSO from a Windows 10–based computer that is

joined to Azure AD
Scenario
A. Datum has an increasing demand to provide its remote and mobile users, who are using Windows 10–
based devices, with secure access to the cloud resources. The company wants to join Windows 10 devices
to Azure AD and simplify access to cloud resources by enabling SSO. Before they can implement this, you
want to test this functionality by joining a Windows 10–based computer to Azure AD.
1. Join a Windows 10-based computer to Azure AD.
2. Authenticate to Azure from a Windows 10 Azure–joined computer.

 Task 1: Join a Windows 10-based computer to Azure AD

1. Sign in to the Azure portal by using your Azure subscription.
2. Verify that the Adatum directory allows users to join their devices to Azure AD.
3. On MIA-CL1, click Settings, click Accounts, and then join MIA-CL1 into Azure AD by using the
following credentials:

4. Verify that MIA-CL1 is shown in the Device tab of the Karen Gruber user account.
 Task 2: Authenticate to Azure from a Windows 10 Azure–joined computer

1. Sign in to MIA-CL1 with Karen Gruber’s credentials:
2. Provide a verification method.

3. Create a PIN.
4. Start Internet Explorer, and then go to https://portal.office.com.
5. Verify that you are automatically signed in as Karen Gruber by using SSO.

Enter:
Reset-Azure
5. You will be prompted to sign in twice. Sign in by using the Microsoft account associated with your
Azure subscription.

Note: This script removes Azure services in your subscription. Therefore, we

recommend that you use an Azure trial pass that was provisioned specifically for this course
The script removes all storage accounts, virtual machines, virtual networks, cloud services,
and resource groups containing these resources.
Results: After completing this exercise, you should have joined the Mia-CL1 computer to Azure AD and
tested the SSO access to the resources in the cloud.
Question: What is the major benefit of joining Windows 10–based devices to Azure AD?
Question: What is the requirement for Delegated Group Management in Azure AD?

Review Question
Question: What are some benefits of hosting part or all of an organization's AD DS in Azure?
Tools
• Microsoft Online Service Sign-In Assistant for IT Professionals. Provides end user sign-in capabilities to
Microsoft Online Services, such as Office 365.
http://aka.ms/Rkgh8c
• Microsoft Azure Active Directory Module for Windows PowerShell (64-bit version). Provides necessary
Windows PowerShell cmdlets for managing users, groups, and devices in Azure AD.
http://aka.ms/Cuedhw
Best Practices:
• Before you implement Azure AD, plan how you want to provide access to applications.
• Separate your testing and production subscriptions to avoid giving employees access to production
services that they do not require.
• Use RBAC to provide users and groups with appropriate permissions to access Azure resources based
on their job profiles.

You don't receive a text or voice call that

contains the verification code for Azure Multi-
Factor Authentication
10-1
Module 10
Managing an Active Directory infrastructure in a hybrid
environment
Contents:
Lesson 1: Extending an on-premises Active Directory domain to Azure 10-2
Lesson 2: Implementing directory synchronization by using Azure AD Connect 10-9
Lesson 3: Implementing federation 10-27
Lab: Implementing and managing Azure AD synchronization 10-36
Module Overview
Three alternative options exist for integrating on-premises Active Directory with Microsoft Azure. These
options are placing a domain controller in Azure, implementing directory synchronization with optional
password synchronization, or single sign-on (SSO) by using Active Directory Federation Services (AD FS).
In this module, you will learn about these options and about how to manage these types of hybrid
environments.
Objectives
After completing this module, students will be able to:
• Extend an on-premises Active Directory domain to Microsoft Azure.
• Synchronize user accounts between on-premises Active Directory Domain Services (AD DS) and
Microsoft Azure Active Directory (Azure AD).
• Set up single sign-on (SSO) by using federation between on-premises Active Directory and Azure AD.
10-2 Managing an Active Directory infrastructure in a hybrid environment
Lesson 1
Extending an on-premises Active Directory domain to
Azure
You can place one or more domain controllers in Azure to enable cloud-based instances of applications
to use the same authentication model that they use in an on-premises infrastructure. The process of
deploying a domain controller in Azure is similar to deploying an on-premises domain controller.
However, there are some differences resulting from the characteristics of Azure virtual machines. For
example, when you deploy a domain controller in Azure, you must place the Active Directory database on
an Azure virtual machine’s data disk. This module focuses on minimizing the costs of running a domain
controller on an Azure virtual machine and on implementing interconnectivity with an on-premises
infrastructure.
Lesson Objectives

• Describe AD DS and Azure AD integration options.
• Explain how to plan to deploy Active Directory domain controllers in Azure.
• Explain how to implement Active Directory domain controllers on Azure virtual machines.

Perform the tasks in this demonstration to prepare the lab environment. While the environment is being
configured, this module will describe the Azure services that you will use in the lab.
Note: The scripts that are used in this course might delete any objects that you have in
your subscription. Therefore, you should complete this course by using a new Azure subscription.
You should have received sign-up details and instructions for creating an Azure learning pass for
this purpose. Alternatively, you can create a new Azure trial subscription. In both cases, use a new
Microsoft account that is not associated with any Azure subscription. This avoids confusion in the
labs and in setup scripts.
The labs in this course use custom Azure cmdlets in the Windows PowerShell command-line interface,
including Setup-Azure to prepare the Azure environment for a lab and Reset-Azure to perform clean-up
tasks at the end of a lab. Setup-Azure removes any current Azure subscription and account details from
the Azure-based Windows PowerShell session.
• Sign in to your Azure subscription.

Demonstration Steps

Setup-Azure
5. When prompted, sign in by using the Microsoft account that is associated with your Azure
subscription.
6. When prompted, enter the Azure region to use, and then press Enter.
Note: This script might remove Azure services from your subscription. We therefore
The script will take 30-40 minutes to configure your Azure environment, which you can use for
the lab at the end of this module.
At the end of setup, you should have:
• A uniquely named storage account.

• A uniquely named cloud service.
• A virtual network named ADATUM-HQ-VNET (10.0.0.0/24).
• An Azure Domain Name System (DNS) named ADATUM-DNS at 10.0.0.4.
• A virtual machine called AdatumDC1 that is running as a domain controller.
Overview of AD DS and Azure AD integration options

Small organizations that do not have an on-
premises directory such as AD DS rely solely on
Azure AD. Microsoft offers cloud-scale identity
and access management via Azure AD, which
provides several options for integrating AD DS
with Azure. These options are:
• Extending on-premises Active Directory to
Azure. With this option, you host virtual
machines in Azure that you then promote to
be domain controllers in your on-premises
Active Directory.
• Synchronizing on-premises Active Directory with Azure AD. Directory synchronization propagates
user, group, and contact information to Azure AD and keeps that information synchronized. In this
scenario, users will utilize different user names and passwords to access cloud and on-premises
resources, and the authentication processes are separate.
• Synchronizing AD DS with Azure AD by using password synchronization. With this option, users can
access Azure AD-aware applications and resources by providing the same password as their current
on-premises sign-in.
• Implementing SSO between on-premises Active Directory and Azure AD. This option supports the
largest range of integration features, and it allows a user to sign in to Azure after authenticating via
the on-premises Active Directory. The technology that is used in this case is federation, which you can
implement by using Active Directory Federation Services (AD FS). AD FS relies on a set of federation
servers and proxies, which starting with Windows Server 2012 R2, take the form of Web Application
Proxy server role service.
Planning to deploy Active Directory domain controllers in Azure

Because Azure provides infrastructure as a service
(IaaS) facilities and can host virtual machines in
the cloud, consider using Azure for hosting
domain controllers and thereby extending the
boundaries of your on-premises domains to the
cloud. Hosting domain controllers in Azure can
provide a range of benefits, both for on-premises
users and for those who connect to on-premises
and Azure-based services from around the world.
Reasons for placing domain controllers in Azure

include:
• Providing resilience to the on-premises

directory.
• Keeping authentication requests for Azure-based services within the Azure environment.
• Extending access to on-premises Active Directory to worldwide sites.
• Enabling additional options such as directory synchronization and SSO with AD FS.
The process of deploying an Active Directory domain controller on an Azure virtual machine is similar to
the process of deploying a domain controller in an on-premises environment. One main difference is that
when you deploy a domain controller in Azure, you must place the Active Directory database on the data
disk of an Azure virtual machine. This avoids potential database corruption that might occur because of
the read and write cache settings of the operating system disk on the Azure virtual machine.
Deployment scenarios
There are three main scenarios to extend on-premises AD DS to resources that exist in Azure. The
different considerations and requirements are based on the deployment scenario that you select:
• Deploy AD DS only on an Azure virtual machine. This scenario involves creation of a virtual network
but does not require cross-premises connectivity. Typically, this deployment starts with a new forest
and all the domain controllers run only on Azure virtual machines. In this scenario, you should
consider setting static IP addresses for domain controllers by using Windows PowerShell or by using
the Azure portal. This scenario is common when you have apps that depend on Kerberos
authentication, but they do not have any requirements that are related to on-premises directory
services.
• Deploy AD DS only in an on-premises infrastructure with cross-premises connectivity. This scenario

keeps existing domain controllers in the on-premises infrastructure, and through a site-to-site virtual
private network (VPN) or Azure ExpressRoute, it extends the authentication and access policy for
resources that exist in the cloud. This scenario requires you to create a virtual network that is
configured for cross-premises connectivity by using site-to-site VPN or ExpressRoute. Additionally, it
requires you to plan IP address allocation carefully to avoid address overlapping. Typically, in this
scenario, internal users and business partners who have some form of federated access to apps, host
the apps in Azure that both users and partners need to access.
• Deploy AD DS in an on-premises infrastructure and on an Azure virtual machine. This scenario is

common for apps that are Lightweight Directory Access Protocol (LDAP)–aware and that support
Windows-integrated authentication. This scenario requires a virtual network with cross-premises
connectivity and proper IP address allocation for virtual machines that are running in the cloud. The
main goal of this scenario is to optimize the cost of solution, considering that inbound traffic is free
but not outbound traffic, and to provide faster performance and a better sign-in experience for users
who access the apps by authenticating to the cloud-based domain controllers.
Planning for deploying Active Directory domain controllers in Azure

The following are some planning considerations for deploying Active Directory domain controllers in
Azure:
• Inter-site connectivity. A key design element is inter-site connectivity between your on-premises
environment and Azure. To ensure that Azure-hosted virtual machines can communicate with internal
domain controllers, you must set up a virtual network with site-to-site connectivity back to your on-
premises network, or you must use ExpressRoute. Cross-premises connectivity requires a VPN server
that supports incoming connections from Azure, a static public IP address on your Internet
connection, and a dynamic gateway for the virtual network to establish connectivity with the on-
premises infrastructure.
• Active Directory sites. You will need to configure sites in AD DS so that you can control replication
traffic between the on-premises and Azure-based domain controllers. Knowledge Consistency
Checker controls the replication process, with intra-site replication relying on a bidirectional ring
topology that assumes high-bandwidth and permanently available connections. Replication traffic is
not scheduled, and updates are optimized for speed. By contrast, inter-site replication uses a least-
cost spanning tree topology with a default three-hour interval that can be restricted to certain times
of the day or week.
• Read-only domain controllers (RODCs). This arrangement reduces the amount of egress traffic and
the resulting Azure service charges. RODCs do not work in situations where a service or application
needs write access to AD DS.
• Flexible single master operations (FSMO) roles and global catalog placement. Regardless of your
domain topology, you should configure all of your Azure-based domain controllers as global catalog
servers. This arrangement prevents global catalog lookups and evaluations of universal group
memberships from having to traverse from Azure to the on-premises global catalog, and therefore,
incurring egress network traffic charges. If Azure domain controllers are in a separate forest, its
operation masters will need to be hosted in Azure. If your Azure domain controllers are in a separate
domain, you will have to put its primary domain emulator master, relative ID master, and
infrastructure master on those virtual machines.
• Backup and restore. Follow the same procedure that you would for an on-premises domain controller
to back up the system state on a domain controller, and avoid using clone virtual hard disk drives that
can introduce an update sequence number rollback effect.
Implementing Active Directory domain controllers on Azure virtual

machines
The requirements for creating a domain controller
on an Azure virtual machine as a replica domain
controller or in a new forest are similar. Both
scenarios require a storage account for creating
the operating system and data disk for the virtual
machine, and as a best practice, you should
configure the domain controller with static IP
addresses. However, additionally, in the first
scenario, you must configure a virtual network for
cross-premises connectivity by using site-to-site
VPN or ExpressRoute.
Install a replica Active Directory domain controller in an Azure virtual machine

To implement a replica domain controller on an Azure virtual machine:
1. Create an Azure virtual network with cross-premises connectivity.
2. Create a storage account.
3. Create a virtual machine and assign an IP address.
4. Install the AD DS and DNS roles on an Azure virtual machine.
The following sections explain these steps in detail.
Create an Azure virtual network with site-to-site VPN

When you create an Azure virtual network for a site-to-site VPN, you need to specify:
• The name of the virtual network.
• The DNS server addresses that point to your on-premises DNS servers.
• Site-to-site VPN connectivity with the on-premises infrastructure. This involves creating a dynamic
gateway with public IP address for establishing a site-to-site VPN tunnel with the on-premises VPN
device.
• The local network that defines the IP address assignment for the on-premises network.
• Virtual network address spaces that define the IP address range for virtual machines that run in Azure.
Note that the address range cannot overlap the address space for your on-premises network.
Additionally, you need to configure an on-premises VPN device with a public IP address and the
configuration rules that will connect to the previously created dynamic gateway.
You can use ExpressRoute instead of site-to-site VPN for cross-premises connectivity. With ExpressRoute,
you can extend your on-premises networks into Azure over a dedicated private connection that is
provided by a connectivity provider. ExpressRoute connections use dedicated lines instead of a public
Internet connection and provide faster speeds, more reliability, and lower latency. To create and provision
an ExpressRoute circuit, perform the following steps:
1. In Windows PowerShell, import the ExpressRoute module by running the following command:
Import-Module 'C:\Program Files (x86)\Microsoft SDKs\Azure\PowerShell\

ServiceManagement\Azure\ExpressRoute\ExpressRoute.psd1'
2. Get the supported list of providers, locations, and bandwidths by running the following
command:
Get-AzureDedicatedCircuitServiceProvider
3. Create an ExpressRoute circuit by running the following command:
New-AzureDedicatedCircuit -CircuitName $CircuitName -ServiceProviderName

$ServiceProvider -Bandwidth $Bandwidth -Location $Location -sku Premium -
BillingType MeteredData
4. Send the service key to your connectivity provider for provisioning.
5. Create your routing configuration.

6. Link a virtual network to the ExpressRoute circuit.
Create a storage account

You require a storage account in which to place the Azure virtual hard disk for the virtual machine
operating system and data disks, with drive caching switched off. This data disk is for the Active Directory
database, log files, and SYSVOL. The following procedure describes the process for creating a storage
account:
2. On the Hub menu, click New, click Data + Storage, and then click Storage account.
3. Select a deployment model: Resource Manager or Classic.
4. Enter a name for your storage account.
5. Specify the type of storage account to create.
6. Specify to enable diagnostics for your storage account.

7. Select a subscription.
8. Specify a new resource group or select an existing resource group.
9. Select the geographic location for your storage account.

10. Click Create to create the storage account.
Create a virtual machine and assign an IP address

You must create a virtual machine with a static IP address from the range in the virtual network scope.
You can use the Azure portal or the Azure module for Windows PowerShell to create a virtual machine
with the Windows Server operating system, and then attach one or more data disks for storing the
database, logs, and SYSVOL.
Install and configure DNS and AD DS server roles.

To promote the server to a domain controller, you need to add and then configure AD DS. Place the
Active Directory database on a data drive with caching turned off.
You can add the AD DS role by using Add Roles and Features in Server Manager or by using the following
Windows PowerShell cmdlet:
Add-WindowsFeature ADDS-Domain-Controller
AD DS setup allows you to automatically add the DNS role to the server. You can also install it afterwards
by using Add Roles and Features in Server Manager or by running the following Windows PowerShell
cmdlet:
Add-WindowsFeature DNS
Install a new Active Directory forest on an Azure virtual network

The requirements to implement a new Active Directory forest in Azure are similar to that needed to create
a replica domain controller. The main difference is that you need to create an Azure virtual network, but
there are no requirements for cross-premises connectivity. Furthermore, the new Active Directory forest
most likely will be the single Active Directory site, and in that case, all domain controllers should be global
catalogs.
To implement a new Active Directory forest in Azure, perform the following steps:
1. Create an Azure virtual network by specifying:
o The name of the virtual network.
o The DNS server addresses that point to the IP address of your new domain controller.
o Virtual Network Address Spaces that define the IP address range for the virtual machines that run
in Azure.
2. Create a storage account. Follow the same procedure as described before.
3. Create the virtual machines to run the domain controller and DNS server roles.
4. Install the AD DS and DNS server roles.

At the end of both processes, to increase security you can implement access control on the endpoints, or
you can design network security groups to limit and control access on domain controllers.
Question: What are the different methods to integrate your on-premises AD DS with Azure?
Lesson 2
Implementing directory synchronization by using Azure
AD Connect
Organizations require control over their identities. They also typically prefer simplifying the process of
accessing Azure resources by enabling the same password access or SSO. Both of these sign-in
experiences require organizations to use the Azure AD Connect tool. This lesson discusses the process
of directory synchronization by using the Azure AD Connect tool. This lesson starts by explaining the
directory synchronization process, it compares the different directory synchronization options, and then it
covers the actual process of directory synchronization. Directory synchronization is a critical process for
most organizations, so you should implement proper management and monitoring processes. You can do
this by using the Azure AD Connect Health tool.
Lesson Objectives
• Describe directory synchronization.

• Compare the different directory synchronization options.
• Identify the directory synchronization option that is best for a given scenario.
• Explain how to prepare on-premises Active Directory for directory synchronization.

• Explain how to install and configure Azure AD Connect.
• Explain how to manage and monitor directory synchronization by using Azure AD Connect Health.
• Explain how to implement Azure AD Domain Services.

• Implement directory synchronization by using Azure AD Connect.
Overview of directory synchronization

Directory synchronization enables user, group,
contact, and Windows 10 device synchronization
between on-premises Active Directory and Azure
AD. In its simplest form, you just install a directory
synchronization component on a server in your
on-premises domain, provide an account with the
Enterprise Admin access to AD DS and another
account with administrator access to Azure AD,
and then let the directory synchronization
component run. All on-premises non-built in
user accounts, groups, contacts, and, optionally,
Windows 10 devices from AD DS will then
replicate to Azure AD. At that point, these accounts will be able to authenticate and, if permitted, access
Azure resources. When you implement password synchronization, users will still be prompted for their
credentials when they first access an Azure resource, even when using computers that are domain
members. However, the difference with password synchronization is that to sign in to an Azure resource,
they can use the same password as their domain sign-in. They can also choose to save the credentials so
that they are not prompted for their password again when they access that resource the next time.
Azure AD Connect
Azure AD Connect is the newest tool from Microsoft that allows organizations to integrate their on-
premises identity systems with Azure AD. Azure AD Connect combines the functionality and components
that have been previously released in the DirSync and Azure AD Sync tools.
Some of the main features of the Azure AD Connect tool are that it:
• Leverages the Microsoft Identity Manager synchronization features.
• Supports multiple forest scenarios.
• Allows for filtering on individual attributes and the synchronization of just those filtered accounts
according to the requirements of specific Microsoft online service, such as Microsoft Exchange Online
or Microsoft SharePoint Online.
• Supports the synchronization of password hashes to Azure AD.

Azure AD Connect uses a very simple wizard to choose the connectivity model between an on-premises
identity infrastructure and Azure. By using the wizard, you choose your topology and requirements such
as single or multiple directories, password synchronization, or federation. Depending on the requirements
that you select, you can enable such options as Azure AD Sync, Exchange hybrid deployment, password
change write-back, device write-back, or AD FS and proxy servers. The wizard deploys and configures all
the required components.
Azure AD Connect is made up of three primary components:
• Synchronization. This is the primary feature of Azure AD Connect responsible for creating users and
groups in Azure AD. The core functionality is taken from Forefront Identity Manager, which uses
connectors for communication among connected directories. They import and export objects on a
predefined schedule, and they can use connector space to filter a subset of attributes and objects.
• AD FS. Provides the core functionality necessary to implement an SSO experience by federating
identities while maintaining full control over authentication in the on-premises environment.
• Health monitoring. Azure AD Connect Health can monitor and gain insight into your on-premises
identity infrastructure and the synchronization services that are available through Azure AD Connect.
Comparing directory synchronization, directory synchronization with

password hash synchronization, and federation
When you run Azure AD Connect, you can choose
to synchronize or federate accounts from on-
premises Active Directory with Azure AD.
Synchronization takes place by replicating the
objects but optionally can include password
synchronization. It is important to understand the
difference between the three options for
providing synchronization between on-premises
Active Directory and Azure AD. These three
options are:
• Directory synchronization
• Directory synchronization with password

synchronization
• Directory synchronization with SSO

Directory synchronization
With directory synchronization, the objects from on-premises Active Directory replicate to Azure AD. For
example, directory synchronization maps user.one@contoso.com from the on-premises Active Directory
to user.one@contoso.onmicrosoft.com in Azure AD. If you create and verify a custom domain in Azure
Active Directory, then you will be able to configure user name match between the two directories, so
that user.one@contoso.com exists in both. Note, that while this is not a requirement for directory
synchronization, you must implement it for the single sign-on and the same sign-on to take effect. Any
change in user one’s attributes in on-premises Active Directory, such as the telephone number, office
location, and so on, will replicate through directory synchronization to Azure AD. At this point, the two
systems maintain passwords separately.
Directory synchronization with password synchronization

Enabling password synchronization alongside the synchronization process provides same sign-in
facilities. So if user one signs in to his or her domain member computer with a user name of
user.one@contoso.com and the password of Pa$$w0rd, the user authenticates by the on-premises
Active Directory. If the user then connects to an Azure-based service or application, he or she will see an
authentication prompt. If the users User Principal Name matches between on-premises Active Directory
and Azure Active Directory, at the prompt, the user will need to enter the same credentials,
user.one@contoso.com as the user name and Pa$$w0rd as the password, to access the Azure-based
resources. When the user accesses the Azure-based resource, Azure AD authenticates the user.
In the background, the password synchronization component takes the user’s password hash from on-
premises Active Directory, encrypts it, and passes it as a string to Azure. Azure decrypts the encrypted
hash and stores the password hash as a user attribute in Azure AD.
When the user signs in to an Azure service, the sign-in challenge dialog box generates a hash of the
user’s password and passes that hash back to Azure. Azure then compares the hash with the one in that
user’s account. If the two hashes match, then the two passwords must also match and the user receives
access to the resource.
The dialog box provides the facility to save the credentials so that the next time the user accesses the
Azure resource, he or she will not be prompted. However, it is important to understand that this is same
sign-in, not SSO. The user still authenticates against two separate directory services, albeit with the same
user name and password. However, for many organizations, the simplicity of this solution, without the
added complexities and costs of an AD FS implementation, makes the lack of true SSO a small price
to pay.
Directory synchronization with SSO

Azure AD Connect provides a simple wizard to deploy and configure AD FS, which in the background
uses directory synchronization to replicate objects to Azure AD. With SSO, directory synchronization
synchronizes user, group, and contact information from on-premises Active Directory to Azure AD—these
objects appear as directory service objects in Azure AD.
The difference between password synchronization and SSO is that in SSO, instead of two separate
authentication processes taking place—one in the on-premises Active Directory and the other in
Azure AD—a federation trust establishes between Azure AD and the on-premises directory. This trust
relationship enables users to access applications and resources in Azure by using their domain accounts in
AD. These users also appear as users in Azure AD, integrated by using SSO with the on-premises Active
Directory. However, the authentication of those users does not take place in Azure AD, but in the on-
premises Active Directory. The next lesson covers this process in detail.
Authorization to access Azure resources is separate from authentication, and it takes place on the
resource side, in this case Azure. The on-premises Active Directory generates a token, which passes to
AD FS and then to Azure by using the federation trust relationship.
Feature comparison
The following table lists the features that each directory synchronization option supports.
Directory
Directory
Directory synchronization with
Feature synchronization with
synchronization only password
SSO
synchronization
Sync users, groups, and Yes Yes Yes

contacts with Azure
Sync incremental updates Yes Yes Yes

with Azure
Enable hybrid Microsoft Yes, limited support Yes, limited support Yes, full support
Office 365 scenarios
Users can sign in with on- No Yes Yes

premises credentials
Reduce password No Yes Yes

administration costs
Control password policies No Yes Yes

from an on-premises
directory
Enable cloud-based Yes Yes Yes

multifactor authentication
(MFA)
Enable on-premises MFA No No Yes
Authenticate against an on- No No Yes

premises directory
Implement SSO with No No Yes

organizational credentials
Customize the sign-in page No No Yes
Limit access to services No No Yes

based on location or client
type
The following table lists the high-level requirements for each directory synchronization option.
Directory
Directory
Directory synchronization with
Requirement synchronization with
synchronization only password
SSO
synchronization
On-premises DirSync server Yes Yes Yes
AD FS server infrastructure No No Yes
AD FS proxy or Web No No Yes

Application Proxy
infrastructure
It is important to understand that if AD FS is unavailable, users will not be able to authenticate, and they
will not be able to use Azure resources. If the Azure AD Connect with Directory Synchronization server is
unavailable, recent attribute changes—including password hashes, if enabled—will not synchronize, but
users will still be able to access resources. Effectively, deploying reliable and highly available SSO has
much higher resource and management demands than either the directory synchronization only option
or the directory synchronization with password synchronization option.
Discussion: Which directory synchronization option is suitable for my

environment?
Work with a partner and discuss which directory
synchronization option would be most
appropriate for your organization. Use the table
from the previous topic to discuss which features
you might need.
Preparing on-premises Active Directory for directory synchronization

When you prepare for directory synchronization,
you should consider a range of factors. The
following sections describe these factors in detail.
Review domain controller requirements

To work with Azure AD Connect, domain and
forest functional levels must be Windows Server
2003 or later. For password write-back feature,
domain controllers must be running at least
Windows Server 2008 with the latest service pack.
Review Azure AD Connect computer

requirements
The computer that is running Azure AD Connect must be running Windows Server 2008 or later, and it
must have the latest hotfixes and updates. For express settings, the computer must be a member server of
a domain or a domain controller, but for custom setting installation, the computer can be a workgroup
computer. If you plan to use Azure AD Connect with AD FS, servers where AD FS and Web Application
Proxy are deployed must be running Windows Server 2012 R2 or later.
In addition, Azure AD Connect requires Microsoft .NET Framework 4.5.1 or later and Windows PowerShell
3.0 or later. For deploying AD FS and Web Application Proxy, you must enable Windows Remote
Management on the servers where you will install these components.
Review hardware recommendations

Deployments with more than 50,000 objects in AD DS require a significant increase in memory—from 4
GB of RAM to 16 GB. Therefore, it is important to implement adequate hardware resources when
transitioning from the pilot to production phase.
Note that if you implemented Azure AD Connect on a virtual machine that is running in Azure, you might
have to scale up the virtual machine if your synchronization requirements increase.
The following table provides guidance on hardware sizing based on the number of objects in AD DS.
Number of objects in Central processing

Memory Hard disk size
AD DS unit (CPU)
Fewer than 10,000 1.6 gigahertz (GHz) 4 GB 70 GB
10,000–50,000 1.6 GHz 4 GB 70 GB
50,000–100,000 1.6 GHz 16 GB 100 GB
100,000–300,000 1.6 GHz 32 GB 300 GB
300,000–600,000 1.6 GHz 32 GB 450 GB
More than 600,000 1.6 GHz 32 GB 500 GB

Review accounts and required permissions

Installing and configuring Azure AD Connect requires the following accounts:
• An Azure AD organizational account with the Global Admin privileges. Create this account in the
directory that you plan to integrate with AD DS.
• An on-premises account with Enterprise Administrator permissions in the on-premises Active

Directory. This account is responsible for creating the synchronization user account in AD DS and to
granting it necessary permissions to read and write during synchronization.
Note: If you use the Azure AD Connect custom setting installation wizard, the on-premises
account does not require Enterprise Administrator privileges, as long as you pre-create the
synchronization user account with sufficient permissions.
Azure AD Connect uses an Azure Global Administrator account to activate directory integration and
create the Azure AD service account that later will provision and update Azure AD objects when the Azure
AD Connect configuration wizard runs.
The Azure AD service account has the prefix “Sync_”, followed by the name of the server that is hosting
Azure AD Connect.
Directory synchronization process creates an AAD_id user account in the Users container of the root
domain of a synchronized forest. This is the account for the synchronization engine running as the
Microsoft Azure AD Sync service on the server where you installed the Azure AD Connect software. The
account has a randomly generated complex password configured to never expire. When the directory
synchronization service runs, it uses the service account credentials to read from the on-premises Active
Directory and then write the contents of the synchronization database to the Azure AD tenant.
Review network ports

Synchronization with Azure AD occurs over Secure Sockets Layer (SSL). This synchronization is outbound
because Azure AD Connect initiates it, and it uses port 443. Internal network communication uses
standard Active Directory–related ports.
The following table provides the required information to plan which ports to enable on the firewall for
successful directory synchronization.
Service Protocol Port
LDAP TCP/User Datagram 389

Protocol (UDP)
Kerberos TCP/UDP 88
DNS TCP/UDP 53
Kerberos change password TCP/UDP 464
Remote procedure call (RPC) TCP 135
RPC randomly allocated high TCP ports TCP 1024–65535

49152–65535
Server Message Block (SMB) TCP 445

Service Protocol Port
SSL TCP 443
SQL TCP 1433
Certificate requirements
All AD FS servers must use the same HTTPS certificate. The AD FS configuration, including the SSL
certificate thumbprint, replicates through a Windows Internal Database (WID) or through a SQL Server
database across all the members of the AD FS server farm. You need to use a certificate that you obtain
from a public certification authority (CA).
Azure AD Connect supporting components

Azure AD Connect installs the following components on the server:
• Microsoft SQL Server 2012 Command Line Utilities
• Microsoft SQL Server 2012 Native Client

• Microsoft SQL Server 2012 Express LocalDB
• Azure Active Directory Module for Windows PowerShell
• Microsoft Online Services Sign-In Assistant for IT Professionals
• Microsoft Visual C++ 2013 Redistributable Package
Review UPN requirements

When you want to synchronize user accounts with Azure AD and you want to implement either the same
sign-on or single sign-on, you need to ensure that you match the UPN for your on-premises Active
Directory with the value that the synchronization process generates for synchronized accounts in Azure
AD. For example, if your organization uses @contoso.com as its UPN suffix, you need to add and verify
contoso.com as a domain in Azure Active Directory. This requirement is to ensure that
userb@contoso.com in the on-premises Active Directory maps to the userb@contoso.com account in
Azure AD when Azure AD Connect runs.
If your on-premises domain uses a UPN that is not routable, such as Contoso.local, then you need to
change the UPN to a routable value that maps to a verified domain in Azure AD. Otherwise, user accounts
will be created in Azure by using the default domain, which will be in the following format:
@usernamedomain.onmicrosoft.com, where usernamedomain represents the value that you specify when
you create the Azure AD tenant. Therefore, it is important to ensure that you have UPNs set up correctly
in your on-premises directory, with the matching domains added to Azure AD before you synchronize.
Clean up AD DS
Before deploying Azure AD Connect, it is essential that you check the on-premises Active Directory for
potential issues, and remediate any issues that you discover. Such checks should include:
• Analyzing the on-premises environment for invalid characters in Active Directory object attributes
and for incorrect UPNs.
• Identifying schema extensions, and custom attributes in use.

• Recording network port use and DNS records that relate to Azure.
When you clean up an on-premises Active Directory, you should note the following attribute
requirements and invalid characters:
Attribute Characters Requirements Invalid characters
proxyAddress 256 Must be unique )(;><][\
sAMAccountName 20 !#$%^&{}\{`~"/[]:@<>+=;
?*
givenName 64 ?@\+
surname 64 ?@\+
displayName 256 ?@\+
mail 256 Must be unique [!#$%&*+/=?^`{}]
mailNickname 64 "\[]:><;
userPrincipalName 64/256 Must be unique in the }{#‗$%~*+)(><!/\=?`

forest
@ character must
exist
Must not include a
space, end in a space,
a period, &, or @
Must be Internet
routable
After you complete the checks, perform the following key remediation tasks:
• Remove duplicate proxyAddress and userPrincipalName attributes.
• Update blank and invalid userPrincipalName attributes, and replace with valid userPrincipalName
attributes.
• Remove invalid characters in the following attributes: givenName, surname, sAMAccountName,

displayName, mail, proxyAddresses, mailNickname, and userPrincipalName.
UPNs that SSO uses can contain letters, numbers, periods, dashes, and underscores; no other characters
are allowed. If the Azure AD integration includes plans for SSO, it is important to ensure that the UPN
names meet this requirement before SSO rolls out, so it is worth considering this factor at this stage even
if you do not currently plan SSO.
IdFix
The IdFix tool enables you to identify and remediate the majority of object synchronization errors in
AD DS, including common issues such as duplicate or malformed proxyAddresses and
userPrincipalName.
You can select the organizational units (OUs) for IdFix to check, and you can fix common errors from
within the tool. Common errors include invalid characters that scripted user imports might have
introduced to attributes.
ADModify.NET
For errors such as format issues, you can make object-by-object changes to specific attributes by using
Active Directory Services Interfaces Editor (ADSI Edit) or Active Directory Users and Computers. However,
to make attribute changes to multiple objects, ADModify.NET is a better tool. The batch mode operation
that ADModify.NET provides is particularly useful for making changes to attributes such as UPNs across
OUs or domains.
Installing and configuring Azure AD Connect

You can install the Azure AD Connect tool by
using express setup, which is typically for simple
deployment scenarios, or custom setup, which is
typically for complex environments.
Additional Reading: Download Microsoft

Azure Active Directory Connect from Microsoft
Downloads: http://aka.ms/Jlpj42.
Azure AD Connect express setup

You can use Azure AD Connect express setup for
directory synchronization with password synchronization for a single Active Directory forest. Express setup
creates a LocalDB instance, which is a lightweight version of SQL Express. Express setup offers the option
to enable Exchange Hybrid Deployment, which will configure the required attribute write-back option.
Azure AD Connect with express settings will:
1. Install the synchronization engine.
2. Configure the Azure AD connector.
3. Configure the on-premises AD DS connector.
4. Enable password synchronization.

5. Configure synchronization services.
6. Configure synchronization services for an Exchange hybrid deployment (optional).
To install Azure AD Connect by using the express settings, perform the following steps:
1. Sign in to the server on which you wish to install Azure AD Connect by using an account with local
administrative privileges.
2. Run the Microsoft Azure AD Connect Setup program (AzureAdConnect.msi).
3. On the Welcome page, select I agree to the license terms and privacy notice, and then click
Continue.
4. On the Express Settings page, click Use express settings.

5. On the Connect to Azure AD page, type the user name and password of an Azure AD Administrator
account, and then click Next.
6. On the Connect to AD DS page, type the user name and password of an AD DS Enterprise
Administrator account, and then click Next.
7. On the Domain and OU filtering page, specify which domains and organizational units to
synchronize, and then click Next.
8. On the Ready to configure page, review the settings, and then click Install.
9. On the Configuration complete page, click Exit.
Custom installation of Azure AD Connect

For complex scenarios that require integration of identities from a multiple-forest environment, or for
deployment of AD FS, you need to use Azure AD Connect custom setup. This allows you to:
1. Specify a custom installation location. This component allows you to specify a different location to
install Azure AD Connect.
2. Use an existing SQL Server. In environments with dedicated database servers, you can select an
existing SQL Server.
3. Use an existing service account. This component allows you to specify an existing service account
instead of the account that is created automatically during Azure AD Connect installation. You need
to specify an existing service account when you use remote SQL Server for connection and
authorization purposes.
4. Specify custom synchronization groups. These groups control what administrative actions you can
execute with the directory synchronization tools by using the existing Active Directory groups. By
default, Azure AD Connect creates local groups on the server, not in AD DS, unless you install it on a
domain controller.
To install Azure AD Connect with password synchronization by using custom settings, perform the
followings steps:
1. Sign in to the server on which you wish to install Azure AD Connect by using an account with local
administrative privileges.
2. Run the Microsoft Azure AD Connect Setup program (AzureAdConnect.msi).
Continue.
4. On the Express Settings page, click Customize.
5. On the Install required components page, you can optionally select one of these options:
o Specify a custom installation location
o Use an existing SQL Server
o Use an existing service account
o Specify custom sync groups

6. On the User sign-in page, select one of the following:
o Password Synchronization. This option synchronizes users passwords to Azure AD via a

password hash.
o Federation with AD FS. This option initiates installation of the AD FS environment, in addition to
installation of AAD Connect.
o Do not configure. This option assumes that you already have an existing federation solution in
place.
7. On the Connect to Azure AD page, type the user name and password of an Azure AD Administrator
account, and then click Next.
8. On the Connect your directories page, specify the Active Directory forest, type the user name and
password of an AD DS Enterprise Administrator account, click Add Directory, and then click Next.
9. On the Domain and OU filtering page, specify which domains and organizational units to
synchronize, and then click Next.
10. On the Uniquely identifying your users page, select the default Users are represented only once
across all directories option, and then click Next.
11. On the Filter users and devices page, you can use synchronization filtering based on Active
Directory group membership.
Note: On the Uniquely identifying your users page, you have the ability to alter how
directory synchronization behaves in multiple-forest environments.
12. On the Optional Feature page, select one of the following options, and then click Next:
o Exchange Hybrid Deployment is used in Microsoft Exchange coexistence scenarios.
o Azure AD app and attribute filtering allows you to further filter what attributes will
synchronize in Azure AD.
o Password synchronization can be enabled as an optional feature if you selected federation as

the SSO solution.
o Password writeback allows changes to account passwords in the cloud and synchronize them
back to an on-premises directory.
o Group writeback works only for Office 365 groups, allowing them to replicate to on-premises
Active Directory as distribution groups.
o Device writeback allows discovered devices in Azure to replicate to an on-premises Active

Directory, which comes handy when implementing conditional access scenarios.
o Directory extension attribute sync provides support for synchronizing custom attributes to
Azure AD.
13. Based on your Azure AD app and attribute filtering selection in the previous step, on the Azure
AD Apps page, you have the option to limit attributes that will be synchronized according to the
Azure apps that your organization is using, such as Microsoft Exchange Online.
14. The Azure AD attributes page also appears only if you select the Azure AD app and attribute
filtering option on the Optional Feature page. On the Azure AD attributes page, you have the
option to select the attributes from on-premises AD DS that you want to synchronize with Azure AD.
For example, you can clear some sensitive attributes that you do not want to synchronize.
15. If you selected Directory extension attribute sync, then on the Directory extension page, you
have an option to extend the schema in Azure AD with custom attributes that exist in your AD DS.
16. On the Configure page, you have to click to complete the custom installation of Azure AD Connect.
Note: A later topic, “Deploying AD FS,” discusses custom AD FS installation.
Configure filtering options

After you install Azure AD Connect, you can use the Synchronization Service Manager to configure
filtering prior to synchronization. For example, you have the option to filter users based on a single group
membership. In addition, it is also possible to use filtering based on:
• Domains. You might also have a domain with resources that you do not want to synchronize with
AD DS.
• OUs. This is one the most frequent filtering options, and you use it to select objects from specific OUs
that will synchronize with Azure AD.
• Attributes. Attribute-based filtering provides an additional level of control. By using this type of
filtering, you can specify individual objects from on-premises AD DS that should or should not
synchronize with Azure AD.
After you decide what is appropriate for filtering, you can select multiple methods or reconfigure them
later based on your requirements.
To configure filtering for domain and OUs in on-premises AD DS, perform the following steps:
1. Start Azure AD Connect.
2. In Microsoft Azure Active Directory Connect, select Customize synchronization options, and then
click Next.
3. After you specify the Azure AD Global Admin credentials and the AD Enterprise Admin credentials,
you will be able to modify domain and OU filtering settings from the Domain/OU Filtering page.
To configure attribute-based filtering in on-premises AD DS, perform the following steps:
1. Start Synchronization Rules Editor.
2. Modify inbound or outbound synchronization rules.
Synchronize directories
After you define filtering for the objects that you plan to synchronize with Azure AD, you can configure
scheduled or manual synchronization. You can perform manual synchronization from the Synchronization
Service Manager or by using Windows PowerShell. In the Synchronization Service Manager, you can
manage Run Profiles that define the process of synchronization. You can configure the following Run
Profiles:
• Full Import
• Full Synchronization
• Delta Import
• Delta Synchronization
• Export
To synchronize objects from AD DS, you need to run the appropriate profile from the Synchronization
Service Manager. Alternatively, for manual synchronization, you can use the Azure AD Connect PowerShell
cmdlet Start-ADSyncSyncCycle.
Managing and monitoring directory synchronization by using Azure AD

Connect Health
You can use Azure AD Connect Health to monitor
and gain insight into your on-premises identity
infrastructure and the synchronization services
that Azure AD Connect provides. Azure AD
Connect Health is an Azure AD Premium feature,
and it uses agents that reside on the Azure AD
Connect server, AD FS, AD FS proxy servers, or
Web Application Proxy servers. These agents
collect information from events, configuration
settings, and performance data, and then send the
collected information to the Azure AD Connect
Health service.
Azure AD Connect Health for sync monitors and provides information on the synchronizations that occur
between your on-premises AD DS and Azure AD. An agent installs during Azure AD Connect installation.
Azure AD Connect Health for Sync provides the following set of key capabilities:
• Alerts provide information about events, configuration details, and synchronization status. For critical
alerts, you can subscribe to receive an email notification. Every alert contains resolution steps, links to
additional documentation, and a history of the previously resolved alerts.
• Sync insight presents information about the latency of the synchronization objects and object change
trends. Information about the latency of synchronization objects is retrieved from the Azure AD
Connect server. This information includes different profiles that can help you understand
synchronization trends. The synchronization objects change trend provides a graphical representation
of the number of successful and failed synchronizations.
To start Azure AD Connect Health, perform the following steps:
2. Locate Azure AD Connect Health by searching for it in the Azure Marketplace or by selecting
Marketplace, and then selecting Security + Identity.
3. On the introductory blade, click Create. This opens another blade with your directory information.
4. On the directory blade, click Create.
Implementing Azure AD Domain Services

Azure AD Domain Services is a cloud-based
service that gives you a fully compatible set of
application programming interfaces (APIs) and
protocols that are commonly used in on-premises
AD DS. Azure AD Domain Services is a managed
Azure service that benefits from proven Active
Directory features such as Kerberos
authentication, NTLM, Group Policy, and LDAP.
With Azure AD Domain Services, you can move
applications that depend on AD DS to the cloud
without deploying and maintaining your own
domain controllers or establishing a site-to-site
VPN with on-premises infrastructure. Azure AD Domain Services offer a cloud-based identity solution that
an administrator can populate with users and groups from on-premises Active Directory through Azure
AD Connect, with the option to synchronize the user password hashes.
How Azure AD Domain Services works

Organizations that use cloud-only Azure AD can enable Azure AD Domain Services for an Azure virtual
network and then get a new managed domain. Users and groups in Azure AD will be available in the
newly created domain, which has directory services similar to on-premises AD DS, such as Group Policy,
Kerberos, and LDAP support. You can join IaaS Windows virtual machines that are created in the Azure
virtual network to the newly created domain, and you can manage them by using basic Group Policy
settings.
Hybrid organizations can integrate their identities from on-premises AD DS with Azure AD DS by using
Azure AD Connect. Users in these organizations can have the same experience while they are accessing
domain-based resources in an on-premises infrastructure or while accessing resources from virtual
machines that run in an Azure virtual network that has been integrated with Azure AD Domain Services.
Note: At the time of writing this module, Azure AD Domains Services is in the preview
phase, and it supports only classic virtual networks.
Demonstration: Implementing directory synchronization by using

Azure AD Connect
• Enable directory synchronization.
• Install Azure AD Connect by using custom settings.
• Synchronize users from on-premises AD DS.

Demonstration Steps
Enable directory synchronization

1. Sign in to MIA-CL1 as Student with the password Pa$$w0rd.
2. In the Internet Explorer window, sign in to the Azure portal by using the Microsoft account that is the
Service Administrator or a co-admin of your Azure subscription.
3. Initiate a Remote Desktop Protocol (RDP) session to AdatumDC1, and then sign in as
ADATUM\Student with the password Pa$$w0rd123.
Create a new Azure Active Directory tenant

1. Once the sign-in is complete, open Internet Explorer and navigate to the Azure classic portal.
2. When prompted, sign in to the Azure classic portal by using an account that is the Service
Administrator or a co-admin of your Azure subscription.
3. In the Azure classic portal, create a new Azure Active Directory tenant with the following settings:
o NAME: AdatumSync
o DOMAIN NAME: Use your initials + the directory name + random numbers (for example,
abcadatum123456). If you get the message The domain is not unique, change the numbers
until you get a green check mark.
Note: Note that you could use Default Directory or any other existing Azure Active
Directory tenant. We chose to create a new Azure AD tenant to eliminate any dependencies on
other modules in this course.
Create a Global Admin account

1. In the Azure classic portal, in the newly created Azure Active Directory tenant, create a new Global
Admin user with the following settings:
o TYPE OF USER: New user in your organization
o USER NAME: SyncAdmin
o FIRST NAME: Sync
o LAST NAME: Admin
o DISPLAY NAME: Sync Admin

o ALTERNATE EMAIL ADDRESS: Type the email address of your Microsoft account
2. Change the temporary password of the newly created user to Pa$$w0rd by using an Internet
Explorer inPrivate Browsing session.
3. Once you change the password, on the No subscriptions found page, click SIGN OUT.
Note: Note that this is expected behavior. The account is a Global Admin of an Azure AD
tenant, but is not the Service Administrator or a co-admin of the subscription, so it does not have
sufficient permissions to sign in to the Azure classic portal.
4. Close the InPrivate Internet Explorer session.
Install Azure AD Connect

1. Open Internet Explorer on AdatumDC1 and download Azure AD Connect from
https://www.microsoft.com/en-us/download/details.aspx?id=47594. You will need to
add https://*.microsoft.com to the list of Internet Explorer Trusted sites.
2. Install the Azure AD Connect tool, select custom settings, and ensure that Password
Synchronization is selected.
3. Set the credentials for Azure AD tenant AdatumSync to the SyncAdmin Global Admin account.
4. Set the credentials for the Active Directory forest to ADATUM\Student with the password
Pa$$w0rd.
5. Accept the default values in the remaining wizard pages, and then start the synchronization process.
Close the wizard once the configuration is completed.
Note: When running the wizard, note the message The directory associated with this
account has no verified domains. You should verify a domain in Azure AD before
continuing. This is expected since you have not verified the domain. You would need to add a
custom domain and verify it if you want to implement the same sign-on or single sign-on,
however, this will not prevent you from implementing directory synchronization.

Reset-Azure
subscription.
The script will take a few minutes to reset your Azure environment and prepare it for the next lab.
groups. The script does not remove the Azure AD directory. You can delete it manually, or you
can leave it as is because it does not affect subsequent labs.
Question: Is there a way to install Azure AD Connect unattended?
Question: Can you rename a server after you install Azure AD Connect on it?
Lesson 3
Implementing federation
AD FS can federate existing AD DS with Azure AD, allowing organizations to benefit from SSO while
accessing cloud resources, and still keeping identity management in their on-premises environments.
Lesson Objectives
• Explain how AD FS and the Web Application Proxy role interoperate.
• Explain how to prepare the environment for deploying AD FS in Azure.
• Explain how to deploy AD FS.
• Explain how to manage and maintain AD FS.
Overview of AD FS and Web Application Proxy

AD FS provides the infrastructure that enables a
user to authenticate in one network and use a
secure service or application in another. AD FS
works seamlessly with AD DS to create tokens that
contain claims about users in an on-premises
directory service and to send those tokens
securely to a relying party. This process of token
exchange enables users to sign in to an Azure
resource by using their Active Directory
credentials.
If a user initiates an authentication request

through AD FS by using an AD FS client such as a
supported browser, AD FS first verifies that the user credentials are successfully authenticated by AD DS.
After successful Active Directory authentication, the security token service (STS) component of AD FS
server then issues a security token to authenticate the user to a cloud service, such as Office 365.
How AD FS works with Azure AD

The following steps describe how AD FS works with Azure AD:
1. A client makes an authentication request to a resource that Azure AD controls.

2. The authentication request redirects to the on-premises federation service, typically through a proxy.
3. The proxy passes the request to the server that is running the AD FS service. AD FS checks that the
user is successfully authenticated by AD DS.
4. AD FS creates a token that contains claims about the user.
5. AD FS passes that token back to Azure AD.
6. Azure AD generates a security token that grants access to the requested resource.
AD FS implements the standards-based Web Services Federation (WS-Federation) protocol and Security
Assertion Markup Language. AD FS enables organizations to implement advanced identity management
solutions such as provisioning, credential mapping, management, deactivation, and change management
of partner accounts.
Authentication occurs through one of a number of methods. AD FS supports:

• Forms authentication, which is the default for Internet-based access.
• Certificate authentication, such as smart card or user client certificates.
• Windows authentication, which is the default for intranet-based request, but this is not supported on
all browsers; the fallback is forms authentication.
AD FS also supports MFA by using device authentication. A user has to use a registered device to access a
resource.
In the AD FS architecture, the AD FS servers for the claims provider connect directly to the domain
controllers of the Active Directory domain, where they can access information about the users held in
AD DS. Because of this privileged access, AD FS servers need the same levels of protection as domain
controllers.
To service access requests from the Internet, AD FS includes an AD FS proxy server role. An AD FS proxy
server typically sits in the perimeter network and intercepts authentication requests, then proxies the
request through to the AD FS servers. The AD FS servers only accept incoming requests from Internet-
based clients through the proxy, and only port 443 (SSL) needs to be open between the proxy and the
AD FS server.
There have been several versions of AD FS since the initial release, including:
• AD FS 1.0 originally released as a Windows component with Windows Server 2003 R2.
• AD FS 1.1 released with Windows Server 2008 and Windows Server 2008 R2 as an installable server
role.
• AD FS 2.0 released as an installable download for Windows Server 2008 Service Pack 2 and later.
• AD FS 2.1 released with Windows Server 2012 as an installable server role.

• AD FS 3.0 is an installable server role on Windows Server 2012 R2. AD FS 3.0 does not require a
separate Internet Information Services (IIS) installation, and it includes a new AD FS proxy role called
Web Application Proxy.
AD FS on Windows Server 2012 R2

In Windows Server 2012 R2, AD FS includes a federation service role service that acts as an identity
provider or as a federation provider. It supports device Workplace Join for SSO and seamless multi-factor
authentication. Devices register in Active Directory through a Device Registration Service (DRS) and use an
X509 certificate bound to the user context on that machine for device authentication. In a default
configuration, users will sign in via AD FS to initiate the joining process by using their Active Directory
credentials.
AD FS can provide conditional access control based on user attributes, such as UPN, email or security
group membership, device attributes such as Workplace Join, and request attributes such as network
location, or IP address.
AD FS in Windows Server 2012 R2 has no dependency on IIS. Instead, the equivalent functionality was
implemented in the kernel mode HTTP.sys, thus providing better performance and a high level of
customization. For increased security, AD FS on Windows Server 2012 R2 has an extranet lockout feature
that allows Web Application Proxy to prevent AD DS accounts from being locked by authentication
attempts originating from the Internet.
Web Application Proxy

To configure AD FS to accept incoming requests from the Internet is through the Web Application Proxy
role service in Windows Server 2012 R2. You must install this server in the perimeter network in a
workgroup. A typical deployment is to use AD FS servers within the organizational network for access by
users on that network, and to use Web Application Proxy servers for users who connect from the Internet.
For authentication, you can implement an MFA adapter that is available as a plug-in for Active
Authentication or from non-Microsoft MFA providers.
Planning for the deployment of AD FS with Azure

AD FS is a full-featured, potentially complex set of
technologies. When planning for AD FS, you
should consider a range of issues.
Plan for devices and browsers

Access to resources in Azure will often be through
browser-based applications. Any current web
browser with JScript enabled can work as an AD
FS client, although Microsoft has only tested
Microsoft Edge, Internet Explorer, Mozilla Firefox,
and Safari on Macintosh.
Cookies must be enabled, or trusted, for the

federation servers and web applications that are being accessed. Cookies prevent repeating prompts for
sign-ins within the same session. The authentication cookie is signed but not encrypted, which requires
SSL support in AD FS.
Plan server placement

The most critical component of an AD FS deployment is the federation server or the server farm.
Therefore, it is important to consider a proper server placement strategy. AD FS servers must be domain
members, and you should place them behind a firewall on the organizational network to prevent
exposure to the Internet. AD FS proxies should not be domain members, and you should install them in a
perimeter network.
Plan server numbers

The number of AD FS servers to deploy in an organization depends on the number of users likely to issue
authentication requests. The recommended minimum requirements are in the following table.
Number of users Minimum number of servers
Fewer than 1,000 0 dedicated federation servers; consider installing the AD FS role on
domain controllers
0 dedicated federation server proxies; install the AD FS role on Web
servers
1,000–15,000 2 dedicated federation servers

2 dedicated federation server proxies
15,000–60,000 Between 3 and 5 dedicated federation servers

At least 2 dedicated federation server proxies
Plan access filtering

You might want to implement access filtering based on claims rules. For example, you might specify that
only users based in a particular location or with a certain domain suffix can access a certain resource in
Azure.
Plan certificates
HTTPS (SSL) communications require a public certificate through a public key infrastructure (PKI); the
certificates for security token signing and encryption can be self-signed by the AD FS server.
All AD FS servers must use the same HTTPS certificate. The AD FS configuration, including the SSL
certificate thumbprint, replicates through a Windows Internal Database (WID) or is shared via a SQL Server
database across all the members of the AD FS server farm. AD FS proxies do not need to use the same
public certificate that internal AD FS servers use because the configuration information is not shared
between the AD FS proxies. Additionally, each AD FS proxy server can use a different SSL certificate, as
long as the common name (CN) on each certificate matches the service name of the internal AD FS
servers. However, all AD FS and AD FS proxy servers can use the same certificates.
Plan AD FS high availability

AD FS can deploy as a stand-alone server or as a server farm. We recommend always using an AD FS
server farm, even if the farm consists initially of just one server, because this provides the option to add
more AD FS servers later for load balancing or fault tolerance. If you deploy AD FS as a stand-alone
federation server, then you cannot add additional servers later.
Network Load Balancing

NLB or other forms of load balancing should be used to allocate a single IP address for multiple
federation server computers. In this way, failure of any single AD FS server will not affect the whole AD FS
service. You should also use NLB to provide an AD FS proxy array in the perimeter network to ensure that
failure of any AD FS proxy computer does not affect external clients.
Plan database servers

AD FS servers require a database, which you can implement as a WID or full SQL Server. If using WID, then
you must configure AD FS servers in a farm as either primary or secondary. The primary federation server
is initially the first federation server in the farm, and it has a read/write copy of the AD FS configuration
database. All other federation servers in the farm (the secondary servers) regularly poll the primary server
and synchronize any changes to a locally stored, read-only copy of the AD FS configuration database. By
default, the poll interval is 5 minutes, but you can force immediate synchronization at any time by using
Windows PowerShell.
Secondary servers provide fault tolerance for the primary server, and with appropriate server placement,
they can load-balance access requests across network sites. If the primary federation server is offline, all
secondary federation servers continue to process requests as normal. However, you cannot make new
changes to the AD FS database until the primary federation server is back online, or a secondary server
is promoted to the primary role. Primary and secondary role assignment is managed by using the
Set-AdfsSyncProperties Windows PowerShell cmdlet.
If SQL Server stores AD FS information, all servers in the farm are considered primaries because they all
have read/write access to the database.
Deploying AD FS
Azure AD Connect simplifies the AD FS installation
process. You need to meet some requirements,
but the process fully automates the installation of
Windows roles and features and their
dependencies. For deploying AD FS, you need to
have:
1. A Windows Server 2012 R2 server for the

federation server.
2. A Windows Server 2012 R2 server for the Web
Application Proxy server.
3. An SSL certificate for the federation service

name that you intend to use.
For proper AD FS deployment design, you must consider additional requirements.
Review account requirements

For AD FS service accounts, you can use domain user accounts or group managed service accounts
(GMSAs) if your environment includes domain controllers that run Windows Server 2012 or later. The
advantage of a GMSA is that it can automatically manage password changes for an account, eliminating
the need to change the password manually.
Review namespace requirements

You need to ensure namespace consistency between on-premises Active Directory and Azure AD. In
summary, this requirement means having UPN suffixes that map to a registered domain name in Azure.
Therefore, if an organization uses a UPN suffix of Contoso.com, then Contoso.com needs to be a verified
domain in Azure AD for that organization’s account.
Review DNS requirements

Client requests to AD FS should resolve to the correct access point of the AD FS service, regardless of
whether the client is on the internal network or on the Internet. Typically, internal clients connect to the
AD FS server, and external clients connect to the proxy (AD FS or Web Application Proxy). However, to
have the same URL for both internal and external connections, you need different entries in the internal
and external DNS to connect to the relevant part of the AD FS infrastructure (split-brain DNS). For
example, if the host name to connect to your AD FS infrastructure is adfs.contoso.com, you will need to
have the following DNS entries:
Internal DNS
Contoso.com zone.
Host name Address
adfs 192.168.0.12
Where 192.168.10.12 is the IP address of the AD FS server farm.
External DNS
Contoso.com zone.
Host name Address
adfs 131.107.21.65
Where 131.107.21.65 is the IP address of the proxy array.
Review certificate requirements

AD FS uses certificates for two purposes:
1. For token exchange
2. For SSL encryption
For token exchange, AD FS uses self-signed certificates. These certificates only validate that content has
been unaltered in transit, so there is typically no requirement to use non-Microsoft issued certificates or to
validate to a trusted CA.
For SSL encryption, certificates must come from a trusted third party, and you do need to replace them
manually before they expire. With non-Microsoft SSL encryption certificates, the CN or the subject
alternative name on the SSL certificate must match the fully qualified domain name (FQDN) of the
endpoint at which client requests are terminating. Therefore, if the DNS name of the STS is
adfs.contoso.com, the SSL certificate for connecting to the proxy array must include a CN or subject
alternative name for adfs.contoso.com. While self-signed certificates offer the benefit of automatic
renewal, you must renew SSL certificates manually for AD FS to remain operational.
Review firewall requirements

Firewall configuration is relatively simple in that external clients only need the SSL port TCP 443 to
connect to the AD FS proxy or the Web Application Proxy endpoint. The proxy then communicates with
AD FS only by using port 443.
Review load-balancing requirements

To provide high availability, AD FS servers typically are configured as server farms, and client requests are
load-balanced across the servers by using NLB or by using hardware load balancers. Load balancer
provides a single IP address for the load-balancing array that you must then associate with the DNS name
representing your AD FS endpoint and include this name as the CN or subject alternative name of the SSL
certificate.
The proxy servers, including Web Application Proxy servers also require load balancing, either by using
NLB or hardware load balancers.
To Install AD FS by using Azure AD Connect, perform the following steps:
1. Run the Azure AD Connect tool.
2. Click the Customize button.
3. On the Install Required Components page, click Install.
4. On the User Sign-in page, select Federation with AD FS, and then click Next.
5. On the Connect to Azure AD page, type the credentials for the account that has the Global Admin
role in the Azure AD tenant with which you want to establish federation.
6. On the Connect to your Directories page, type the credentials for the account that has sufficient
permissions for on-premises Active Directory.
7. On the Domain and OU filtering page, specify the filtering options.
8. On the Uniquely identifying your users page, select how users are identified in the on-premises
AD DS.
9. On the Filter users and devices page, specify whether to synchronize all users or select group
filtering to limit the number of users and groups from AD DS that will synchronize with Azure AD.
10. On the Optional Features page, you can further control synchronization options by selecting
password synchronization or password writeback.
11. On the AD DS Farm page, select Configure a new Windows Server 2012 R2 AD FS farm. Browse
to and select the certificate for SSL, and then provide the password for the certificate.
12. On the Specify the AD FS page, you can add one or more servers that are already joined in AD DS.
13. On the Specify Web Application Proxy page, select the server that resides in the perimeter network.
14. On the Proxy trust credentials page, type the credentials for the user account that has local
administrative privilege on the server in the perimeter network. That account will establish
connectivity with Web Application Proxy.
15. On the AD FS service account page, select Group Managed Service Account (gMSA) or domain user
account. This account will authenticate users and look up user information in AD DS.
16. On the Azure AD Domain page, select the domain that you want to federate with Azure AD. This will
result in a configuration where AD FS will issue security tokens to Azure AD and configure Azure AD
to trust these tokens.
17. On the Ready to Configure page, review the installation steps, and then select Start the
synchronization process as soon as the configuration completes. Click Install.
18. After the installation completes, you can verify AD FS functionality by clicking Verify.
Managing and maintaining AD FS

After you deploy AD FS, you will likely need to
perform a number of management tasks.
Manage the certificate life cycle

To prevent issues from certificate expiration,
the self-signed certificates that AD FS generates
support automatic rollover through
AutoCertificateRollover, which renews AD FS
certificates once a year. If you decide to use an
internal PKI to issue the token signing certificate,
AD FS does not provide AutoCertificateRollover,
and you will need to handle certificate renewal
manually. You can view certificate expiration dates
for the service communications, token-decrypting, and token-signing certificates by using the AD FS
Management console. In the console tree, expand Service, and then click Certificates. You can also use
the Get-ADFSCertificate Azure AD PowerShell cmdlet to view certificate details.
Convert domains to federated

Configuring on premises Active Directory forest as federated creates the relying party trust between Azure
AD and the new on-premises domain. After conversion, every synchronized on-premises user becomes a
federated user, and they can use their organizational credentials to access resources in Azure. If you need
to add an additional Active Directory domain and convert it to federated, you can run Azure AD Connect
again.
Monitor AD FS with Azure AD Connect Health

You can monitor AD FS functionality by using Azure AD Connect Health, which uses agents that reside on
AD FS servers, AD FS proxy servers, or Web Application Proxy servers. These agents collect information
from events, configuration settings, and performance data, and they send the information to the Azure
AD Connect Health service. You can then view this information in the portal:
• In the Alerts view, you can view information about active alerts that are based on events,
configuration information, and synchronization status of AD FS. For critical alerts, you can subscribe
to receive an email notification. Every alert contains resolution steps, links to additional
documentation, and a history of the previously resolved alerts.
• In the Usage Analytics view, you can view information about successful logins, the authentication
method, and the number of users who are accessing applications. The information displays based on
audit reports from AD FS servers Note that audit reports are not turned on by default.
• In the Monitoring view, you can view a summary of performance counters that are collected from
AD FS servers, such as CPU utilization, memory, and latency.
To install an Azure AD Connect Health agent on the AD FS server, perform the following steps:
1. Sign in to the Azure portal with the global administrative account.
2. In the Azure Marketplace, locate the Azure AD Connect Health extension.
3. Download the Azure AD Connect Health agent for AD FS.
4. Double-click the .exe file that you download.
5. Click Install, and then follow the installation procedure.

6. After the installation completes, click Configure Now.
7. This opens Windows PowerShell with elevated privileges. Run the Register-
AzureADConnectHealthADFSAgent cmdlet.
8. Sign in to Azure, and then finish the agent configuration.
Question: What is the difference between a single AD FS server and a farm?

Lab: Implementing and managing Azure AD

synchronization
Scenario
A. Datum Corporation users rely on SSO to access on-premises applications. While evaluating Azure for
A. Datum, you need to verify that A. Datum users can use their existing credentials to access resources in
Azure, including non-Microsoft software as a service (SaaS) applications. You need to verify that any
password or Active Directory user and group account changes in on-premises Active Directory
automatically replicate to Azure AD.
Objectives
• Configure directory synchronization.
• Synchronize on-premises Active Directory with Azure Active Directory.
Lab Setup

User name: Student
Password: Pa$$w0rd
Exercise 1: Configuring directory synchronization

Scenario
A. Datum plans to implement directory integration. To test the planned implementation, you need to
deploy and configure Azure AD Connect to synchronize your on-premises AD with a test Azure AD tenant.
To eliminate the need to verify a custom DNS domain, you will be using the default DNS name of the test
Azure AD domain.
1. Sign in to the Azure VM hosting an Active Directory domain controller.
2. Create a new Azure AD tenant and a Global Admin account.
3. Install Azure AD Connect with custom settings.
 Task 1: Sign in to the Azure VM hosting an Active Directory domain controller

2. In the Internet Explorer window, sign in to the Azure portal by using the Microsoft account that is the
Service Administrator or a co-admin of your Azure subscription.
3. Initiate a Remote Desktop Protocol (RDP) session to AdatumDC1, and then sign in as
ADATUM\Student with the password Pa$$w0rd123.
 Task 2: Create a new Azure AD tenant and a Global Admin account

1. After the sign-in is complete, open Internet Explorer and navigate to the Azure classic portal.
3. In the Azure classic portal, create a new Azure Active Directory tenant with the following settings:

o NAME: AdatumSync
4. In the Azure classic portal, in the newly created Azure Active Directory tenant, create a new Global
Admin user with the following settings:
o FIRST NAME: Sync
o LAST NAME: Admin

5. Change the temporary password of the newly created user to Pa$$w0rd by using an Internet
Explorer inPrivate Browsing session.
6. Once you change the password, on the No subscriptions found page, click SIGN OUT.
 Task 3: Install Azure AD Connect with custom settings

1. Open Internet Explorer on AdatumDC1, and then download Azure AD Connect from
https://www.microsoft.com/en-us/download/details.aspx?id=47594. You will need to add
https://*.microsoft.com to the list of Internet Explorer Trusted sites.
2. Install the Azure AD Connect tool, select custom settings, and then ensure that Password
Synchronization is selected.
3. Set the credentials for Azure AD tenant AdatumSync to the SyncAdmin Global Admin account.
4. Set the credentials for the Active Directory forest to ADATUM\Student with the password
Pa$$w0rd123.
5. On the Domain and OU filtering page, limit synchronization to objects in the Accounts
organization unit only.
6. Accept the default values in the remaining wizard pages, and then start the synchronization process.
Close the wizard once the configuration is completed.
Note: You might need to wait a few minutes for the initial synchronization to complete.
7. In the Azure classic portal, navigate to the adatumsync Active Directory page. Click USERS, and then
confirm that the list of users includes all the names from the Accounts organizational unit (OU).
Results: After completing this exercise, you should have installed and configured Azure AD Connect, and
you should have it ready for test synchronization.
Exercise 2: Synchronizing directories

Scenario
A. Datum wants to test Azure AD synchronization by changing a few attributes of a user account and then
performing manual synchronization.
1. Modify attributes of an Active Directory user and Initiate manual synchronization.
 Task 1: Modify attributes of an Active Directory user and Initiate manual

synchronization
1. On AdatumDC1, change the following attributes of some of your users in the Accounts OU of the
Adatum directory:
o Job Title: VP
o Department: Marketing
2. Start a Windows PowerShell session by using administrative credentials.
3. At the Windows PowerShell command prompt, type the following command, and then press Enter:
Get-ADSyncScheduler
Start-ADSyncSyncCycle –PolicyType Delta
4. On the Azure classic portal, check that the changes that you made to the user accounts have
replicated to Azure; if you do not see any changes, wait for a few minutes, and then refresh the page.
5. Close the AdatumDC1 remote desktop session, and then click OK when prompted.

1. On MIA-CL1, close all open applications without saving any files.

Reset-Azure
subscription.
Note: This script might remove Azure services in your subscription. We therefore
The script will take 5-10 minutes to reset your Azure environment and make it ready for the next
module. The script removes all storage, virtual machines, virtual networks, cloud services, and
resource groups.
Important: The script might not be able to get exclusive access to a storage account to delete it;
if this occurs, you will see an error. If you find objects remaining after the reset script is complete,
you can rerun the Reset-Azure script, or you can use the Azure classic portal to delete all the
objects in your Azure subscription manually, with the exception of the default directory.
Results: After completing this exercise, you should have changed attributes on a user account, and then
forced synchronization.
Question: How do you configure organizational unit (OU)–level filtering for directory
synchronization?
Question: When do you use Azure AD Connect custom setup?


Review Question
Question: How can you integrate users, groups, and devices from AD DS with Azure AD?
Tools
The following table lists the tools that this module references.
• Microsoft Online Service Sign-In Assistant for IT Professionals RTW. Provides end-user sign-in
capabilities to Microsoft cloud services such as Office 365.
http://aka.ms/prtkih
• Microsoft Azure Active Directory Module for Windows PowerShell (64-bit version). Provides necessary
Windows PowerShell cmdlets for managing users, groups, and devices in Azure AD.
http://aka.ms/Xzzhol
• Microsoft Azure Active Directory Connect. Enables directory synchronization or federation of on-
premises AD DS users with Azure AD.
http://aka.ms/Jlpj42

Typical issues that can lead to problems

include:
• Installation errors, such as using
incorrect on-premises or Azure AD
credentials.
• Inadvertently deactivating directory
synchronization in the portal or
through the Windows PowerShell
command-line interface.
• Unexpected changes in AD DS that
affect OU scoping or attribute filtering.
• Corrupted AD DS, requiring directory
recovery.
11-1
Module 11
Implementing Azure-based management and automation
Contents:
Lesson 1: Implementing OMS 11-2
Lesson 2: Implementing Azure Automation 11-9
Lesson 3: Implementing Automation runbooks 11-16
Lesson 4: Managing Azure Automation 11-24
Lab: Implementing Automation 11-29
Module Overview
Microsoft Operations Management Suite (OMS) and Azure Automation are services that you can use to
monitor and manage Microsoft Azure and on-premises resources. In this module, you will learn about
these services, their architecture, and their main characteristics. You will also study the process of
implementing the most common OMS solutions. This module also describes the different types of
runbooks that Azure Automation supports, and how you can publish and execute these runbooks.
Objectives
• Implement OMS solutions.
• Implement the core components of Azure Automation.
• Implement different types of Azure Automation runbooks.
• Manage Azure Automation by publishing runbooks and scheduling their execution.

11-2 Implementing Azure-based management and automation
Lesson 1
Implementing OMS
OMS is a service that provides monitoring, analytics, and management capabilities for both on-premises
and cloud resources. You can derive significant benefits from these capabilities in a variety of business
scenarios, ranging from tracking, auditing, or troubleshooting past events, to forecasting and capacity
planning.
This lesson describes the level of integration between OMS and other Azure services. It also describes the
architecture and extensibility of OMS, and the steps you need to follow to implement it.
Lesson Objectives
• Describe the role of OMS in the context of overall Microsoft Azure offerings.
• Describe the architectural components of OMS.

• Implement an OMS workspace and populate it with solutions and data connection sources.

• Launch Windows PowerShell as Administrator
• Run Setup-Azure
• Specify the module number and confirm your selection
• Sign in to your Azure subscription
• Select the Azure region to use during the demonstration and lab
Important: The scripts used in this course might delete any objects that you have in your
Microsoft account that is not associated with any other Azure subscription. This avoids confusion
in labs and setup scripts.
The demonstrations and labs in this course use custom PowerShell modules, including Setup-Azure to
prepare the environment for a demonstration or a lab, and Reset-Azure to perform clean-up tasks
afterwards. For this module, Setup-Azure first creates an infrastructure as a service (IaaS) V1 storage
account and an IaaS V1 virtual network named ADATUM-HQ-VNET in the region you specify. Next, it
deploys an IaaS V1 virtual machine named AdatumSvr1 that is using the storage account to store its disks
and residing in the newly created virtual network. Afterwards, the script removes any cached Azure
subscription and account information from the Windows PowerShell session.
classroom location. You will need this information during the lab setup and the lab.
Demonstration Steps
Prepare the environment

Setup-Azure
4. Confirm your selection by typing Y, and then press Enter.
6. When prompted, provide the number corresponding to the Azure region that you want to use for the
Azure services that this script creates.
Note: The script will take a few minutes to complete.
Introducing OMS
Operations Management Suite extends the
functionality implemented originally in Azure
Operational Insights, which, in turn, superseded
Microsoft System Center Advisor. Knowing the
lineage of the service helps to understand
references to Operational Insights throughout
this lesson and within the Azure classic portal
interface. In short, Operational Insights handles
log collection, analytics, and extensive search
capabilities. OMS, which includes Operational
Insights, also provides a range of management
features, leveraging a number of Azure services
such as Automation, Backup, and Recovery Services.
Architecture
From the architectural standpoint, the OMS service operates as a web service, which interacts with a
number of distinct components that facilitate data collection, analysis, and visualization. The OMS
architecture consists of the following components:
• Connected data sources represent monitored systems, which belong to one of three main categories:
o Windows or Linux server or Windows client operating system running the Microsoft Monitoring
Agent connected to the OMS service (the agent is available for Windows 32-bit and 64-bit
systems, in addition to Linux).
Note: These systems can reside on-premises, in Azure, or in datacenters that other cloud
providers manage.
o System Center Operations Manager (SCOM) management groups, including all systems that are
part of these groups. Considering that SCOM is supported on-premises and in Azure, the
integration with OMS is available in each of these scenarios.
o Azure IaaS V1 Storage accounts used by Azure IaaS V1 VMs configured with the Windows Azure
Diagnostic VM extension or the Linux Azure Diagnostic VM extension, or by Azure platform as a
service (PaaS) Cloud Service worker and web roles with the Windows Diagnostic VM extension.
• OMS repository designates Azure-based storage for data that OMS collects from connected sources.
• OMS workspace constitutes the administrative and security boundary of the OMS environment. It
also defines the scope of data collection, analysis, and visualization. Each workspace has a unique
Workspace ID and is associated with the primary and secondary key. Knowledge of these parameters
(the ID and at least one of the two keys) is necessary to join a system to the workspace (this is
equivalent to the way of controlling access to an Azure Storage account). You can create multiple
workspaces in the same Azure subscription.
• OMS solutions build on the core functionality of the service by implementing logic. This logic derives
meaningful information from row data collected from connected data sources. Some of the OMS
solutions also extend the scope of collected data. All currently available solutions appear in the OMS
Solutions Gallery. You can browse through this list and add them directly to your workspace.
• OMS portal provides a web-based interface for configuring OMS data collection, managing OMS
solutions, and viewing results of OMS-based analytics for the solutions that you added to the
workspace.
Solutions
OMS solutions deliver functionality to customers and constitute the primary method of extending the
service. Due to this extensibility, you can easily add to the workspace any solution that is available in the
OMS Solutions Gallery. However, it is important to keep in mind that adding solutions impacts pricing and
the volume of the collected data, which has bandwidth and storage implications.
The most commonly used solution packs include:

• Log Search. Provides the ability to collect and parse logs from connected data sources.
• Malware Assessment. Checks the status of antivirus and antimalware scans on monitored systems.
• System Update Assessment. Identifies missing system updates on monitored systems.

• Azure Site Recovery. Monitors replication status of systems that Azure Site Recovery Vault protects.
• Backup. Oversees the status of Azure IaaS VM Backup and Windows Server backup to an Azure
Backup Vault. The Backup solution pack also integrates with the Azure classic portal interface,
simplifying the management experience.
• Change Tracking. Tracks configuration changes on monitored systems.
• Automation. Integrates with Azure Automation, delivering its status and statistics data and simplifying
management by providing links to Azure Automation–related features in the Azure portal.
Other solution packs available at the time of writing this course include AD Assessment, AD Replication
Status, App Dependency Monitor, Alert Management, Azure Networking Analytics, Capacity Planning,
Configuration Assessment, Container, Security and Audit, SQL Assessment, Surface Hub, and Wire Data.
Service pricing
OMS pricing depends on a number of factors. Significant discounts are available to organizations with
System Center Standard or Datacenter licensing agreements, but separate purchase of the service is also
possible. The pricing tier also affects the solution pack entitlements, such as the volume of uploads and
the retention of log data that Operational Insights utilizes, for example.
To become familiar with OMS, you can use the Free tier subscription option. At the time of writing this
course, the Free tier subscription allows for uploading up to 500 megabytes (MB) of data daily, with the
seven-day retention period. However, you should be aware that the Free tier does not allow for the use of
some of the solution packs, such as Backup.
OMS as a component of Azure

OMS has a unique role in the Azure range of
services. Its primary purpose is to facilitate the
monitoring and analysis of your existing on-
premises and cloud-based environments. It also
offers some management capabilities through
integration with other Azure services such as
Azure Automation, Azure Backup, or Azure Site
Recovery. You can implement its functionality
through extensions known as solution packs,
which you can easily add after provisioning the
core service.
OMS supports IaaS V1 VMs and PaaS Cloud

Services, in addition to IaaS V2 VMs. It also allows you to collect and analyze Azure IaaS V1 VM
diagnostics data residing in IaaS V1 Azure Storage accounts. Its scope extends to on-premises systems, by
relying on agents deployed to on-premises computers, or by leveraging integration with System Center
Operations Manager.
Introduction to implementing OMS solutions

To implement OMS solutions, perform the
following steps:
1. From the Azure classic portal, create an

Operations Insights workspace. You will need
to specify:
o A unique name, in the

portal.opinsights.azure.com DNS
namespace
o The service tier—free, standard, or

premium
o The Azure region to host the workspace
2. Alternatively, you have the option to sign up for OMS without an existing Azure subscription by
going to the OMS website at http://microsoft.com/oms.
3. Once you have activated the workspace, you should connect to it. To do so from the Azure classic
portal, on the DASHBOARD page of your workspace, click Visit your Operational Insights account.
To connect to the workspace from within the OMS portal, click the Get started tile.
4. Select the solutions that you want to use. By default, your workplace will already include the Log
Search capability.
5. To collect data, you also need to add connected data sources. The method you need to use depends
on the location and type of target systems. For example:
o To add servers running the Windows Server operating system, or clients running the Windows
operating system, which are not SCOM clients and which are located either on premises or in a
cloud, download and install the Microsoft Monitoring Agent on each of them. The download link
is available directly from the OMS portal. The installation will require you to provide the
workspace ID and one of two workspace keys (primary or secondary).
o To add servers running the Windows Server operating system, or clients running the Windows
operating system, which are SCOM clients, use the Operational Insights Connection from the
Operations Manager console targeting the SCOM management server. You can install the
Microsoft Monitoring Agent manually and specify the management group that the local
computer is part of, but this approach is less efficient.
o To add diagnostics data from Azure IaaS virtual machines (Windows or Linux) and from Azure
PaaS Cloud Services web and worker roles configured with the Azure Diagnostic VM extension,
specify the Azure Storage account that stores the data.
6. Specify one or more logs from which you want to upload content to the OMS repository. You have
the option to enable data collection for Windows Event logs, Windows performance counters, Linux
performance counters, Internet Information Services (IIS) logs, custom fields, and Syslog.
Note: You can enable Operational Insights on Azure IaaS V1 virtual machines directly from
the Azure classic portal, without the need for manually downloading and installing the agent.
Once data is uploaded to the OMS Repository, the service analyzes its content by applying logic defined
by the solutions you added to the workspace. The portal displays the outcome of this analysis on its home
page. From here, you can perform log searches and view information generated by individual solution
packs.
Demonstration: Implementing OMS solutions

• Create an Operational Insights workspace.
• Install the Microsoft Monitoring Agent on an Azure IaaS VM.
• Add solutions to OMS.
• Perform searches of collected data.
• Configure log collection.

Demonstration Steps
Create an Operational Insights workspace

1. Ensure that you are signed in to MIA-CL1 as Student with the password Pa$$w0rd, and that the
setup script you ran in the previous demonstration to prepare the environment has completed.
2. Sign in to the Azure classic portal by using the Microsoft account of the Service Administrator or
Co-Administrator of your Azure subscription.
3. From the Azure classic portal, create an Operational Insights workspace with the following settings:
o ACCOUNT: Create a new account

o WORKSPACE NAME: a unique name (in the portal.opinsights.azure.com namespace) between 4
and 24 characters in length
o TIER: Free
o LOCATION: an Azure region close to your location
4. Wait until the workspace creation completes. This should take no more than a minute.
Add solutions to OMS

1. From the newly created workspace, navigate to the Operational Insights account.
2. When prompted, provide your Microsoft account with which you signed in to the Azure classic portal
as the email for the Operational Insights account.
Note: If you are not redirected to the Microsoft Operations Management Suite Provide
Email page, proceed directly to step 5.
3. If prompted, sign in to your email account, open the email with the subject Confirm Your Email
Address for Microsoft Operations Management Suite, and then click the Confirm Now link.
4. Ignore any prompts related to Silverlight being out of date.
5. From the Microsoft Operations Management Suite interface, add all recommended solutions to the
newly created workspace.
Install the Microsoft Monitoring Agent on an Azure IaaS VM
Note: If you are presented with the Session Expired dialog box when stepping through
this demo, click Refresh, type your email address in the Confirm email address text box, select
Don’t ask me again check box, then click CONFIRM & CONTINUE, and finally click SKIP THIS
STEP AND CONTINUE.
1. Click CONNECTED SOURCES at the top of the page of the Microsoft Operations Management
Suite interface.
2. Switch back to the Azure classic portal. From the newly created workspace on the Operational
Insights page in the Azure classic portal, enable Operational Insights for AdatumSvr1.
3. Do not wait until the Microsoft Monitoring Agent is installed on AdatumSvr1 and ignore any
errors reported on the page. Instead, switch back to the CONNECTED SOURCES tab of the
Microsoft Operations Management Suite page.
4. Switch back to the CONNECTED SOURCES tab of the Microsoft Operations Management Suite
page.
5. Download and install Windows Agent (64-bit). Use the Connect the agent to Microsoft Azure
Operational Insights option. Provide the Workspace ID and its primary key when prompted. Leave
the remaining settings with their default values.
6. Refresh CONNECTED SOURCES tab of the Microsoft Operations Management Suite page and
verify that the SERVERS CONNECTED link increased by one.
Review the search functionality

1. Navigate to the Search page of the Microsoft Operations Management Suite interface.
2. If prompted, step through the Search quick tips.
3. Click Favorites. In the Saved Searches pane, click All Configuration Changes.
Note: Note that at this point, most likely data collected from the client computer has not
been indexed yet, so it will not be displayed in the results pane.
Configure log collection

1. From the Microsoft Operations Management Suite interface, enable collection of Windows
System Event logs, including Error, Warning, and Informational events.
2. Return to the home page. From here, you can perform log searches and view information generated
by the solution packs you included in your workspace. You can also add other solutions from
Solutions Gallery.

Question
Which of the following resources can you monitor and manage by using Microsoft
OMS?
An IaaS VM running Linux
A PaaS Cloud Service worker role
A PaaS web app
An Azure Storage account
An on-premises computer running the 32-bit Enterprise edition of Windows 8

Lesson 2
Implementing Azure Automation
In this lesson, you will learn about the architecture, capabilities, and main components of Azure
Automation. You will learn about the process of creating an Azure Automation account and its assets.
In addition, you will become familiar with extending the scope of Azure Automation to on-premises
systems by leveraging Hybrid Runbook Workers.
Lesson Objectives
After completing this lesson, you should be able to:
• Identify the role of Azure Automation in the context of the overall Azure offering.
• Describe the architecture of Azure Automation and list its components.
• Explain how to create an Azure Automation account and its assets.
• Describe how to use Automation runbooks on-premises.

• Create an Azure Automation account and its assets.
Introducing Azure Automation

Azure Automation has undergone significant
enhancements since its introduction as a cloud-
based service. Initially, its capabilities were limited
to managing Azure-resident services. It relied
exclusively on Windows PowerShell workflows,
which you could typically create via the Azure
classic portal–based textual editor. Since then, not
only has Azure Automation become available on-
premises, but you can also use it with Windows
PowerShell scripts, which are considerably more
familiar to a typical information technology (IT)
professional. You can now mitigate the challenges
of creating workflows by using a graphical editor to create them, directly from the Azure portal. In
addition, both Azure-based IaaS virtual machines and on-premises systems can benefit from the support
for Desired State Configuration (DSC). DSC integrates with Azure Automation, ensuring that the state of
managed resources does not change over time in an uncontrolled manner.
The core component of Azure Automation is an account. An Automation account serves as a container of
automation components, such as Azure PowerShell modules, scripts, and workflows, or credentials and
certificates used to connect to other Azure services. You can create multiple Automation accounts per
Azure subscription. For example, you might want to separate management of your development and
production environments, with each of them containing different settings. You can define these settings
by creating automation assets, which include Windows PowerShell modules, credentials, certificates,
connections, schedules, and variables.
When working with Azure Automation, another term that you will encounter often is activity. You might
find this term confusing, because it appears in two distinct contexts. The first one refers specifically to
Windows PowerShell workflow activities. It is important to realize that, while you express activities by
using the same verb-noun combination as Windows PowerShell cmdlets, you implement them differently
(by using Windows Workflow Foundation). As the result, there are some unique rules that dictate how you
can use Windows PowerShell workflow activities. We will explore these rules in the next lesson of this
module. The second meaning of the term activity is generic and represents an individual automation task
that you implement, which typically refers to either a Windows PowerShell cmdlet or a Windows
PowerShell workflow activity.
Additional Reading: For more information, refer to Azure Automation in Depth: Runbook
Authoring: http://aka.ms/B9r14h.
Assets and activities become building blocks of Windows PowerShell workflows and scripts, which result in
the creation of Automation runbooks. Runbooks deliver the core functionality of the Azure Automation
service, executing your custom scripts either on demand or according to your chosen schedule. Each unit
of runbook execution is referred to as a job.
Another approach to delivering the equivalent functionality of runbooks relies on Windows PowerShell
DSC. This technology, introduced in Windows PowerShell 4.0, allows you to define a configuration that
you can apply to managed computers and then deliver to them in the push or pull manner. Push indicates
that you actively deploy configuration to target computers. With the pull approach, target computers
periodically copy configuration from a designated location, known as a pull server. Azure Automation
allows you to create such configurations, store them on an Azure-resident DSC pull Server, and apply
them to Azure IaaS virtual machines.
Automation runbooks run in Azure, so, by default, they cannot directly target your on-premises resources.
However, it is possible to accomplish this by deploying intermediary systems known as Hybrid Runbook
Workers. These systems, operating typically in groups for resiliency reasons, reside on your local network
and communicate with Azure Automation to execute its runbooks against local computers.
Azure Automation as a component of Azure

Azure Automation is an Azure service with the
primary objective of automating a variety of
repetitive and long-running tasks, both in Azure
and on-premises. With the introduction of the
Desired State Configuration component, Azure
Automation also allows you to maintain consistent
configuration of managed resources.
Azure Automation relies on Windows PowerShell

and Windows PowerShell workflows to provide
the automating functionality. As the result, you
can implement any noninteractive procedure, as
long as it is possible to script it with PowerShell.
You can manage virtually any cloud-hosted service by using Azure PowerShell. As a result, your
inventiveness and scripting skills play a large part in determining the scope of application for Azure
Automation.
The most common uses of Azure Automation include scheduled provisioning and de-provisioning of
Azure IaaS virtual machines (including both IaaS V1 and IaaS V2) or PaaS Cloud Services. Workflows
provide additional resiliency, automatically resuming any interrupted tasks.
Creating Azure Automation accounts and assets

To configure Azure Automation, you must first
create an Automation account. As the previous
topic mentioned, the Automation account defines
the scope for other Automation components,
including assets and runbooks.
You can create an Automation account by using

the Azure classic portal or the Azure portal;
however, your choice has compatibility
implications. In particular, accounts that you
create in the Azure portal are not accessible from
the Azure classic portal. However, the Azure portal
provides access to any Automation account,
regardless of the method you used to create it, as long as you have the required permissions.
Azure Automation assets represent configurable components that you can use to build Automation
runbooks. The assets are grouped into the following six categories:
• Modules. Windows PowerShell modules imported into an Automation account. Modules determine
the sets of cmdlets that are available when you create Windows PowerShell scripts and workflows. By
default, any newly created account contains a number of Windows PowerShell modules, including
Azure, AzureRM.Compute, AzureRM.Profile, Microsoft.PowerShell.Core,
Microsoft.PowerShell.Diagnostics, Microsoft.PowerShell.Management, Microsoft.PowerShell.Security,
Microsoft.PowerShell.Utility, Microsoft.WSMan.Management, and
Orchestrator.AssetManagement.Cmdlets.
Note: Both Service Management and Azure Resource Management modules are available,
which means that Automation supports both deployment models.
In the context of Azure Automation, Windows PowerShell modules are referred to as integration
modules, with one important distinction. While both types of modules must contain at least one
.psd1, .psm1, or .dll file (which implements the actual cmdlets), an integration module might also
contain a metadata .json file. This JavaScript Object Notation (JSON) file defines the Azure connection
type that Automation should use when accessing resources that the cmdlets included in the module
target. You must compress the entire content of the integration module into a .zip file to be able to
upload it to an Azure Automation account.
• Schedules. By using schedules, you can execute runbooks automatically (rather than on demand),
either once at a designated date and time, or in a recurring manner.
• Certificates. This category consists of certificates uploaded to an Azure Automation account. One
common way of using them is for facilitating certificate-based authentication. To retrieve the value of
a certificate asset, use the Get-AutomationCertificate activity.
• Connections. Connections contain the information required for a runbook to connect to an external
service or application, such as a user name and password, a computer to connect to, certificate
name, or subscription ID. You can access connection properties in the runbook with the
Get-AutomationConnection activity. Connection type definitions are included in the integration
modules that deliver related Windows PowerShell functionality. To make a specific connection type
available, you need to import the module that contains the connection type definition.
• Variables. This category contains values that you need to reference in your scripts. By using variables,
you avoid the need to modify your runbooks directly (potentially multiple times) if the referenced
value changes. Variables are also useful for sharing values between runbooks, sharing values between
multiple jobs executing the same runbook, and managing values initially set from the Azure portal or
from Windows PowerShell. To retrieve variables, use the Get-AutomationVariable activity.
• Credentials. Credentials consist of a user name and password combination. To retrieve a credential
within a runbook, you can use the Get-AutomationPSCredential activity. The credential must
represent a Microsoft Azure Active Directory (Azure AD) account, because Azure Automation does
not support Microsoft accounts.
It is possible to encrypt content related to some of the Automation assets, including credentials,
connections, and variables. Once the encryption takes place, to retrieve the protected content, you must
use runbook activities rather than the corresponding Windows PowerShell cmdlets.
Using Automation runbooks on-premises

Because it runs in the cloud, Azure Automation
has direct access to Azure-hosted services. On the
other hand, because it runs in the cloud, Azure
Automation cannot manage on-premises
resources in the same manner. To manage these
resources, you would have to open internal
networks to inbound traffic originating from
Azure, which customers generally are not willing
to do. To remediate this, Azure Automation
supports the deployment of designated on-
premises systems referred to as Hybrid Runbook
Workers, which provide missing functionality
without jeopardizing security, by relying exclusively on outbound communication to Azure.
Hybrid Runbook Workers are on-premises systems running Windows Server 2012 or newer that leverage
Microsoft Management Agent to communicate with both Azure Automation and Microsoft OMS. The
former delivers core automation components, which include runbooks and the execution parameters and
instructions associated with them. The latter provides monitoring and agent maintenance.
To ensure resiliency, you typically deploy Hybrid Runbook Workers in groups, though it is possible to have
a single worker in a group. You reference the group name when you start a runbook. Azure Automation
automatically designates one of the group members to execute the corresponding job.
The process of deploying a Hybrid Runbook Worker consists of the following tasks:
1. Create an OMS workspace, assuming that one does not already exist.
2. Add the Automation solution to the OMS workspace.
3. Install the Microsoft Management Agent on the on-premises computer running Windows Server 2012
or newer, which will be serving the Hybrid Runbook Worker role.
Note: Refer to the first lesson of this module for more information regarding the above
steps.
4. Run the Add-HybridRunbookWorker PowerShell cmdlet on the Hybrid Runbook Worker computer
to establish its communication with the Azure Automation workspace. The cmdlet is part of the
HybridRegistration PowerShell module, which Hybrid Runbook Worker downloads automatically
once you add the Automation solution to the OMS workspace. The cmdlet includes, as one of its
parameters, the name of the group of which the Hybrid Runbook Worker will become a member. If
the group does not exist, it is created at this point. The remaining parameters are the Automation
account URL and its access key, which you can retrieve from the automation account blade in the
Azure portal.
In addition, you will likely need to install PowerShell modules that the runbook relies on during its
execution, because these are not automatically deployed to the worker computer. To run an Azure
Automation runbook on-premises, you need to specify the Run on option (either via the Azure portal
interface or by including the –RunOn parameter when invoking the Start-AzureAutomationRunbook
cmdlet) and specify the name of the target Hybrid Runbook Worker Group as its value.
Note: At the time of writing of this course, Hybrid Runbook Workers do not support Azure
Automation–based DSC configurations.
Demonstration: Creating an Azure Automation account and assets

• Create an Automation account.
• Create an Azure AD user account.
• Create an Azure Automation Credential asset.

• Create an Azure Automation Variable asset.
• Create an Azure Automation Schedule asset.
Demonstration Steps
Create an Automation account

1. Ensure that you are signed in to MIA-CL1 as Student with the password Pa$$w0rd.
2. Sign in to the Azure portal by using the Microsoft account that is the Service Administrator or
3. Create a new Azure Automation account with the following settings:
o Name: DemoAutomationAccount
o Resource group: +New
o New resource group name: AutomationRG
o Subscription: your current subscription

o Location: an Azure region that you chose when running the provisioning script
o Create Azure Run As account Yes.
Note: Wait for the Automation account to be provisioned. This should take less than a
minute.
Create an Azure AD user account

1. From the Azure classic portal, create a new user in the default directory of your Azure subscription,
o USER NAME: AutomationUser
o @: leave the default value
o ROLE: user
o Multi Factor Authentication: disabled
o DISPLAY NAME: Automation User
2. From the Azure classic portal, configure the new user as a Co-Administrator of the current
subscription.
3. Change the temporary password of the newly created user to Pa$$w0rd.
Create an Azure Automation Credential asset

1. Switch back to the Azure portal page displaying the Automation account that you created at the
beginning of this demonstration.
2. Create a new Azure Automation credential asset with the following settings:
o Name: DefaultAzureCredential
o Description: Automation User (Co-Administrator)
o User name: the name of the newly created AutomationUser account that you copied to Notepad
Create an Azure Automation Variable asset

1. Create a new Azure Automation Variable asset with the following settings:
o Name: SubscriptionName
o Description: Subscription Name
o Type: String
o Value: name of your subscription
o Encrypted: No
2. Create another Azure Automation Variable asset with the following settings:
o Name: VMName
o Description: VM Name
o Type: String
o Value: AdatumSvr1
o Encrypted: No
3. Create one more Azure Automation Variable asset with the following settings:
o Name: ServiceName
o Description: Service Name
o Type: String
o Value: the name of the cloud service containing AdatumSvr1 that you identified earlier in this
demonstration.
o Encrypted: No
Create an Azure Automation Schedule asset

• Create a new Azure Automation Schedule asset with the following settings:
o Name: EndOfDay
o Description: End of Day
o Starts: tomorrow’s date at 18:00:00

o Recurrence: Daily
o Runs every (number of days): 1
o Set expiration: clear this check box
o Expires: Never

Question
You need to be able to execute Azure Automation runbooks on your on-premises

computers. What additional Azure service do you need to configure?
ExpressRoute
OMS
Service Bus
PaaS Cloud Service
App Service
Lesson 3
Implementing Automation runbooks
In this lesson, you will learn about implementing Azure Automation runbooks. In particular, you will learn
about three types of Automation runbooks, and the process of authoring each of them. In addition, you
will become familiar with the implementation of DSC, which relies on Azure Automation.
Lesson Objectives
After completing this lesson, you should be able to:
• Describe the different types of runbooks that Azure Automation supports.
• Explain how to create Automation runbooks by using the graphical authoring functionality in the
Azure portal.
• Explain how to create basic PowerShell workflows by using sequences, checkpoints, and parallel
processing.
• Explain how to author Automation runbooks based on PowerShell workflows.
• Explain how to author Automation runbooks based on PowerShell scripts.
• Explain how to implement DSC that leverages Azure Automation.
• Author Azure Automation runbooks by using the graphical interface.
Introduction to Azure Automation runbooks

Runbooks deliver the core functionality of Azure
Automation by serving as containers for your
custom scripts and workflows. In addition,
runbooks typically reference Automation assets,
such as credentials, variables, connections, and
certificates. They also can contain other runbooks,
thereby allowing you to build more complex
workflows. You can invoke and run runbooks
either on demand or according to your chosen
schedule by leveraging Automation Schedule
assets.
In general, there are two types of Azure

Automation runbooks, based on how you create and edit their content:
• Graphical. You can create and edit graphical runbooks only by using the graphical editor interface
available in the Azure portal.
• Textual. You can create and edit textual runbooks either by using the textual editor available in the
Azure portal, or by using any PowerShell or text editor and importing the runbooks into Azure.
You can also categorize Automation runbooks by whether they contain PowerShell scripts or workflows. It
is worth noting that graphical runbooks support only PowerShell workflows, but textual ones can
accommodate both types.
Your choice of a runbook type is important, because it is not possible to perform conversion between the
graphical and textual types. Other considerations include:
• Graphical runbooks significantly simplify implementing PowerShell workflows, with built-in visual
elements representing checkpoints and parallel processing.
• PowerShell workflow–based runbooks take longer to start because they must be compiled first.
• PowerShell script–based workflows do not support workflow-specific features such as checkpoints or

parallel processing.
In addition to authoring, you also have the option to export and import runbooks, which provides a
relatively convenient method of copying them across Automation accounts. This approach is available for
both graphical and textual runbooks.
Graphical authoring of Automation runbooks

Graphical authoring of Azure Automation
runbooks greatly simplifies the creation of
PowerShell workflow–based code, eliminating the
need for scripting in many cases. Authoring relies
on the graphical editor available in the Azure
portal. It involves selecting visual elements
representing different activities and arranging
them on canvas within the editor window.
The Library control displays all available activities,

which are grouped into four sections:
• Cmdlets. Lists all the available PowerShell

cmdlets organized according to the
PowerShell module to which they belong. In this section, you will find all the PowerShell modules that
you imported into the Automation account.
• Runbooks. Includes all runbooks within the current Automation account. You have the option of
adding these runbooks to the canvas as child runbooks.
• Assets. Provides easy access to all automation assets in the current Automation account.
• Runbook Control. Contains additional activities that allow you to dictate the flow of execution, or
incorporate custom code within the current runbook. For example, a junction allows you to combine
multiple, parallel execution paths into one. A workflow script gives you the ability to add a custom
PowerShell workflow or script that the built-in activities do not implement.
Once you drop an activity onto the canvas, you can configure its individual settings, such as parameters of
PowerShell workflow activities. You can do so from the Configuration control, which appears on the right
side of the editor window. The editor interface also includes the Test control, which allows you to test the
execution of the runbook that you are currently editing.
Overview of PowerShell workflows

A workflow is a sequence of steps optimized for
long-running tasks, or multiple steps across
multiple managed nodes, such as Azure IaaS
virtual machines. In the context of PowerShell, you
implement workflows by using Windows
Workflow Foundation.
Windows PowerShell workflows largely resemble

traditional Windows PowerShell scripts, because
they use the same verb-noun syntax for their
activities. Most PowerShell cmdlets are effectively
represented by their identically named activities.
However, there are also significant differences
between Windows PowerShell workflows and scripts.
One of the unique characteristics of workflows is the ability to recover automatically from failures that
could be the result of, for example, reboots of managed nodes. Checkpoints make this automatic recovery
possible. Checkpoints designate points in the workflow where the workflow engine should save the
current status of the execution. In addition, workflows can perform groups of commands in parallel,
instead of sequentially, as in typical PowerShell scripts. This is useful for runbooks that perform multiple
actions that take a significant time to complete, such as provisioning a collection of virtual machines.
Checkpoints also mitigate the throttling mechanism known as Fair Share, which Azure Automation
includes. This mechanism temporarily unloads any executing runbook, and prevents it from proceeding
after it has been running for three hours. When Fair Share restarts the runbook afterwards, it resumes its
execution from its most recent checkpoint or, if one does not exist, from the beginning. The latter would
likely result in the runbook execution being interrupted again after three hours. If a runbook restarts from
the same checkpoint or from the beginning three consecutive times, Fair Share terminates it permanently
with the failed status. You should consider this behavior when authoring your automation runbooks.
Additional Reading: For more information, refer to PowerShell Workflows: The Basics:
http://aka.ms/Wlt7zp.
Authoring Azure PowerShell workflow runbooks

Windows PowerShell workflows start with the
keyword Workflow, followed by the script body
enclosed in braces, as follows:
Workflow Test-Workflow1
{
<Activities>
}
The keyword Parallel creates a script block

containing multiple activities that run concurrently
(enclosed in braces). The keyword ForEach
–Parallel implements concurrent processing of
items in a collection. This allows you to ensure
that a sequence of activities in a script block that follows ForEach –Parallel runs in parallel for each item
in the collection. The keyword Sequence enforces sequential processing of arbitrarily chosen activities
(enclosed in braces) if they reside within a parallel script block.
In the following example, activities A and B (and the sequence C-D) will execute in parallel, and there is no
way to know in advance which of these activities will complete first. Activities C and D will always execute
in order (first C, then D), but might execute before activity A or activity B.
Workflow Test-Workflow2 {
Parallel {
Activity A
Activity B
Sequence {
Activity C
Activity D
}
}
In general, it is likely that you will not be able to copy an existing Windows PowerShell script and
implement it directly as a PowerShell workflow without making any modifications. It might be necessary
to perform some level of conversion, by translating PowerShell cmdlets into their corresponding Windows
PowerShell workflow activities and accounting for syntactical differences between the two programming
models. For PowerShell cmdlets that you cannot easily map to workflow activities, you can use the
InlineScript construct, which is effectively a Windows PowerShell script block inside your workflow. The
keyword InlineScript designates a block of PowerShell cmdlets that run in a separate, non-workflow
session, returning the final result to the workflow. Windows PowerShell, not Windows Workflow
Foundation, processes the content of an InlineScript block.
InlineScript {
Non-mapped cmdlets
}
Checkpoints are snapshots of the current state of the workflow, including the current values for runbook
variable assets. Checkpoints are saved to the Automation database, so that workflows can resume after an
interruption or outage. You set checkpoints with the Checkpoint-Workflow activity. You can use the
Suspend-Workflow activity to force a runbook to suspend, and set a checkpoint. This is useful for
runbooks that need some intermediate manual steps.
To create a new textual Windows PowerShell workflow–based runbook from the Azure portal, in the Add
Runbook blade within your Automation account, click the Quick Create Create a new runbook option,
specify the runbook name (which must start with a letter, but might include numbers, underscores, and
dashes), and ensure that you select PowerShell Workflow as the runbook type.
When authoring Azure PowerShell workflow–based textual runbooks, you have several options:
• Write code directly in the textual editor window within the Azure portal.
• Add PowerShell cmdlets contained in the PowerShell modules imported into your Automation
account.
• Reference Automation assets (including variables, connections, credentials, or certificates) by using

either Get or Set activities. For example, to reference a value of an Automation variable asset, you
would right-click it, and then click either Add “Get Variable” to canvas or Add “Set Variable” to
canvas. This would automatically add the Get-AutomationVariable activity to the canvas, with the
–Name parameter set to the value of this variable.
• Add runbooks of the same type (meaning either graphical or PowerShell workflow textual) to the
canvas. This adds the reference to this runbook within the editor window, which results in invoking
the imported runbook during execution of the currently edited one. For example, if you add a
PowerShell workflow runbook named Runbook1 to the canvas, it would appear in the editor window
as a separate line in the format Runbook1.ps1.
Authoring Azure PowerShell runbooks

When authoring Azure PowerShell–based
runbooks, you have several options:
• Write code directly in the textual editor

window within the Azure portal.
• Add PowerShell cmdlets contained in the

integration modules imported into your
Automation account.
• Reference Automation assets, including

variables, connections, credentials, or
certificates, by using either Get or Set
activities. For example, to reference a value of
an Automation variable asset, you would right-click it, and then click either Add “Get Variable”
to canvas or Add “Set Variable” to canvas. This would automatically add the Get-
AutomationVariable activity to the canvas, with the –Name parameter set to the value of this
variable.
• Add runbooks of the same type to the canvas. This adds the reference to the runbook within the
editor window, which results in invoking the imported runbook during execution of the currently
edited one. For example, if you add a PowerShell runbook named Runbook1 to the canvas, it would
appear in the editor window as a separate line in the format .\Runbook1.ps1.
To create a new textual Windows PowerShell workflow–based runbook from the Azure portal, in the Add
Runbook blade within your Automation account, click the Quick Create Create a new runbook option,
specify the runbook name (which must start with a letter, but might include numbers, underscores, and
dashes), and ensure that you select PowerShell as the runbook type.
Implementing Automation DSC

DSC allows you to define in a declarative manner
an operating system or application state and
enforce this state by applying this definition to
one or more managed computers via the push
approach or the pull approach. The push
approach is initiated from a central management
point, whereas the pull approach is initiated from
managed computers. With the pull approach, the
definition is first copied to a pull server that
managed systems point to as their configuration
source.
Azure Automation leverages the Windows PowerShell DSC in the pull mode, implementing all of its
components in the cloud. It is capable of managing both Windows and Linux systems running on Azure
IaaS V1 VMs, Azure IaaS V2 VMs, and on-premises computers.
The Azure DSC implementation process starts with creating a configuration script (a .ps1 file) that
represents the desired state of managed computers. Configuration contains one or more nodes, which
represent individual roles that you want to manage. You must add the configuration to the Automation
account, by using either the Azure portal or Windows PowerShell. Just like PowerShell scripts and
workflows, the configuration script can reference Automation assets.
The scope of functionality that you are able to manage with Azure Automation DSC depends on the DSC
resources that the Automation account includes. While there is a set of built-in resources that match those
in the standard PowerShell DSC, it is possible to import additional resources if needed, by uploading
PowerShell integration modules containing their definitions. The upload functionality is available from the
Azure portal and by using Azure PowerShell.
Next, you need to compile DSC configuration by clicking the Compile link in the configuration blade in
the Azure portal, or by invoking the Start-AzureRmAutomationDscCompliationJob cmdlet. When
using PowerShell, you have the option to specify configuration data during compilation. This allows you
to assign different configurations, depending on the targeted computers. For example, you can enforce
one set of settings on the production system and another in a test environment.
Compilation generates one or more Managed Object Format (MOF) files containing node configurations,
which are uploaded to a DSC pull server residing in Azure (along with non-default DSC resources). For
these configurations to take effect, you need to add (or onboard, in the DSC nomenclature) target
computers as DSC-managed nodes into your Automation account. In general, you can carry out the
onboarding process from the Azure portal or by using Azure PowerShell. However, there are some points
to consider during the onboarding process:
• Azure Linux VMs do not have support for Azure portal onboarding, so you have to use PowerShell.
• Azure classic VMs do not appear in the Select VMs blade for Azure portal onboarding. However, you
can add them by installing the Azure Automation DSC Extension from the Azure portal.
As part of onboarding, you will need to specify registration settings, including:
• Registration URL. This setting is available from the Manage Keys blade in the Automation account in
the Azure portal.
• Automation account registration primary or secondary key. This setting is available from the Manage
Keys blade in the Automation account in the Azure portal.
• Node configuration name. This setting specifies the name of the configuration node.
• Refresh frequency. Its value determines how often the nodes communicate with their DSC pull server.
• Configuration mode frequency. Its value determines how often nodes apply configuration mode to
their local resources.
• Configuration mode. It can take one of the following values:
o ApplyAndMonitor. Applies the configuration and monitors any subsequent inconsistencies,

recording them in logs.
o ApplyOnly. Applies the configuration once.
o ApplyAndAutoCorrect. Applies the configuration and fixes any subsequent inconsistencies.
Additional Reading: For more information, refer to DSC Configurations

http://aka.ms/Vy5n2q.
Additional Reading: For more information, refer to Onboarding machines for

management by Azure Automation DSC: The Basics: http://aka.ms/Lmsccl.
Demonstration: Graphical authoring of Automation runbooks

• Create a graphical Automation runbook.
• Configure authentication in a graphical Automation runbook.

• Add an activity to start an Azure VM.
Demonstration Steps
Create a graphical Automation runbook

2. Navigate to the DemoAutomationAccount Automation account that you created in the previous
demonstration of this module.
3. Add a graphical runbook to the Automation account with the following settings:
o Name: Demo-GraphicalRunbook
o Runbook type: Graphical
o Description: Demo Graphical Runbook
4. Wait until the runbook gets provisioned.
Configure authentication in a graphical Automation runbook

1. Open Demo-GraphicalRunbook in the graphical editor in the Azure portal.
2. Add the Add-AzureAccount cmdlets to the canvas.

3. Set the CREDENTIAL parameter of the Add-AzureAccount cmdlet to the DefaultAzureCredential
Automation credential asset.
4. Leave the remaining parameters of the Add-AzureAccount cmdlet as not configured.
Add an activity to start an Azure VM

1. Add the Start-AzureVM cmdlet to canvas of the Azure Automation graphical editor.
2. Connect the Add-AzureAccount activity to the Start-AzureVM activity on the canvas.
3. Configure the value of the Parameter set of the Start-AzureVM activity to ByName.
4. Configure the Start-AzureVM activity parameters by using the following settings:
o NAME: VMName variable asset
o SERVICENAME: PowerShell expression set to
$serviceName = Get-AzureVM | Where-Object {$_.Name -eq 'mpVM1'} | foreach

{$_.ServiceName}
$serviceName

Question
You plan to author an Automation runbook that, according to your estimates, will
take seven hours to complete. What should you do to ensure that the runbook
successfully executes?
Create a PowerShell script–based runbook
Create a PowerShell workflow–based runbook with a single checkpoint
Create a PowerShell workflow–based runbook with two checkpoints
Create a PowerShell workflow–based runbook with a single Inlinescript element
Create a PowerShell workflow–based runbook with two Inlinescript elements

Lesson 4
Managing Azure Automation
In this lesson, you will learn about the most common Azure Automation management tasks, focusing on
runbook lifecycle management. This lesson will cover testing, publishing, and scheduling automation
runbooks, in addition to monitoring and troubleshooting Automation jobs. The lesson concludes with an
overview of the most common troubleshooting techniques and different methods to ensure resiliency of
your Azure Automation environment.
Lesson Objectives
• Describe the lifecycle of Azure Automation runbooks.
• Describe the process of testing, publishing, and executing Automation runbooks.
• Explain how to monitor and troubleshoot runbook execution.

• Explain how to protect the Azure Automation environment.
• Test, publish, execute, and monitor an Automation runbook.
Automation runbook lifecycle

Any runbook residing in an Automation account
has a specific authoring status, depending on its
stage of development:
• A newly created runbook that you have not

yet published is assigned the New authoring
status automatically. In this stage, you can
modify and test it, but you cannot schedule
its execution. You also do not have the option
to revert any changes that you save.
• Once you successfully complete testing on a

runbook, you can publish the runbook. At this
point, the runbook is automatically assigned
the Published authoring status. This, in turn, allows you to schedule its execution. This is a typical,
production-ready status of a runbook. In addition, it is possible to start a published runbook by
submitting an HTTP POST request to a URL referred to as Webhook. You can create a Webhook via
the Azure portal or Azure PowerShell.
• If you decide to author changes to an existing, published runbook and open it in the textual or
graphical editor, it will be assigned the In edit status. This allows you to modify and test it. Any
changes that you save do not affect the published version. In addition, you have the option to revert
the edited version back to the published one.
You can easily identify the current status of any runbook from the Runbooks blade in the Azure portal,
which is visible in the AUTHORING STATUS column.
Testing, publishing, and executing Automation runbooks

To test a runbook, in the Azure portal, click Test
pane in the toolbar of the graphical or textual
editor blade. Testing allows you to validate
runbook operation before making the runbook
available for production use. This is possible
without overwriting an existing, published version.
Depending on the runbook type, you can initiate
testing from the graphical or textual editor, and
monitor results of its execution in the Output
blade. It is important to note that, during a test,
the edited runbook runs against the target
environment that you specify, so you should
evaluate the risk of such an action. In other words, testing is not functionally equivalent to the –WhatIf
PowerShell switch.
Note: Because, by default, runbook tests run against a live environment, you might want to
consider creating a dedicated test subscription or an on-premises Hybrid Runbook Workers
group. When you have the final version of a runbook, you can then export it, and import it into
your production subscription.
To publish a runbook that you validated through testing, in the Azure portal, click Publish in the toolbar
of the graphical or textual editor blade. Once you publish a runbook, you can link it to one or more
schedules, with different recurrence settings (one time, hourly, and daily) and an expiration date. You have
the option of enabling or disabling individual schedules without affecting others linked to the same
runbook. You can also modify input parameters if the runbook accepts them, and run settings. By default,
runbooks run on Azure, but if you deploy a Hybrid Runbook Worker group, you can also run them on-
premises. You also have the option to execute a published runbook on demand. You can do this by
clicking Start in the toolbar of the runbook blade in the Azure portal.
Regardless of the method, invoking execution of a runbook creates an automation job. A runbook job
represents a single execution of a runbook. This implies that you have the ability to run multiple instances
of the same runbook simultaneously or according to overlapping schedules.
Monitoring and troubleshooting Automation jobs

You can control and monitor each automation job
by using its blade in the Azure portal. The
interface provides you with the ability to stop,
resume, and suspend the job’s execution,
depending on its current status. From here, you
also have access to job summary information, the
job’s output, and errors, warnings, exceptions, and
logs that it generates. Alternatively, you can
retrieve job status information by using the
Get-AzureAutomationJob PowerShell cmdlet.
When monitoring and troubleshooting jobs, you should be aware of their possible states, which include:
• Completed. Designates successful completion of the job.
• Failed. For PowerShell workflow–based runbooks, which includes all graphical runbooks, this indicates
a compilation failure. For PowerShell script–based runbooks, this typically is a result of an exception in
the script execution.
• Failed, waiting for resources. Implies that the job has failed because it has reached the limit of three
consecutive restarts following the Fair Share–based unload.
Note: The previous lesson in this module described the Fair Share mechanism.
• Queued. Designates the state of waiting for resources necessary to initiate job execution.
• Starting. Follows the Queued state, once the platform has assigned necessary resources to the job.
• Running. Designates the job actively performing activities included in the runbook.
• Running, waiting for resources. Indicates that the job has been unloaded because it reached the Fair
Share limit by running for three hours. The job will resume from the most recent checkpoint.
• Stopped. Indicates that a stop request by the owner of the Automation account has stopped the job
prior to its completion.
• Stopping. Describes a job in the process of stopping prior to its completion, following the stop
request by an administrative user with sufficient permissions to the Automation account.
• Suspended. Results from the request to suspend the job. Such request can be initiated by an
administrative user with sufficient permissions to the Automation account, by the Azure platform (in
case of an exception), or by a command in the runbook.
• Suspending. Indicates that the platform is attempting to suspend the job following a request from an
administrative user with sufficient permissions to the Automation account. Note that the job will have
to reach its next checkpoint, or complete if a checkpoint does not exist, before it changes its status to
Suspended.
• Resuming. Follows the Suspended state and is typically a result of an administrative action.
Protecting the Azure Automation environment

It is important to consider protecting your Azure
Automation configuration beyond the resiliency
mechanisms that the cloud platform provides. By
default, Azure geo-replicates the content of each
Automation account to another secondary region,
automatically paired up with the one you choose
as the primary. Both regions reside in the same
geography. The secondary replica becomes
available in case of a disaster affecting the region
that hosts the primary.
Azure also offers a 90-day default data retention period, affecting the length of time during which you
can view and audit past jobs. This period also designates the time after which the platform permanently
removes administratively deleted automation objects, such as accounts, assets, modules, runbooks, or DSC
components.
If these provisions do not satisfy your requirements, you have the option of backing up your Automation
environment by using the following methods:
• Export runbooks from the Azure portal or by running the

Get-AzureAutomationRunbookDefinition PowerShell cmdlet.
• Maintain integration modules outside of an Automation account, because it is not possible to export
them.
• Extract and store definitions of unencrypted assets by running Azure PowerShell cmdlets, because
assets also are not exportable. To retrieve encrypted values of Automation variable and credential
assets, use the equivalent Automation activities (Get-AutomationVariable and
Get-AutomationPSCredential).
• Export DSC configurations by using the Azure portal and
Export-AzureRmAutomationDscConfiguration.
Demonstration: Testing, publishing, executing, and monitoring execution

of an Automation runbook
• Test a runbook.
• Publish a runbook.
• Execute a runbook and monitor the corresponding job.
Demonstration Steps
Test a runbook
2. Navigate to the DemoAutomationAccount Automation account that you created in the second
demonstration of this module.
3. Open the AzureAutomationTutorial runbook in the Edit PowerShell Runbook blade.
4. Test execution of the AzureAutomationTutorial runbook. Monitor the progress of the execution
and view the output of the test execution.
Publish a runbook
• Publish the newly tested runbook.
Execute a runbook and monitor a job

1. Execute the newly published runbook.
2. Monitor the Job Summary tile. Note that other tiles allow you to access Errors, Warnings, All Logs,
Input, and Output.
3. Once the job completes, in the Output blade, verify that you can see the same results as those
following the test.

Reset-Azure
subscription.
groups.
directory.

Question
What actions are available for a runbook in the New authoring status?
Testing
Scheduling
Creating a Webhook
Reverting to the published version
Editing
Lab: Implementing Automation

Scenario
A. Datum Corporation wishes to minimize administrative overhead as much as possible, especially for
tasks such as deploying and deprovisioning VMs. For this reason, as part of A. Datum’s evaluation of
Microsoft Azure, you have been asked to test the new Azure Automation features and, as part of your
tests, to deploy Azure VMs by using runbook automation.
Objectives
• Configure Automation accounts.
• Create runbooks.
Lab Setup

User name: Student
Password: Pa$$w0rd
Before starting this lab, ensure that you have performed the “Preparing the Azure environment”
demonstration tasks at the beginning of the first lesson in this module, and that the setup script has
completed.
Exercise 1: Configuring Automation accounts

Scenario
Administrators at A. Datum Corporation spend considerable time creating storage accounts and Azure
VMs. You want to increase administrator productivity by using Automation to execute these tasks and
freeing administrators to continue with other tasks.
1. Create an Automation account.
2. Create an Azure AD user.
3. Create Automation assets.
 Task 1: Create an Automation account

setup script you ran in the previous demonstration to prepare the environment has completed.
2. Sign in to the Azure portal by using the Microsoft account that is the Service Administrator or Co-
Administrator of your Azure subscription.
3. Create a new Azure Automation account with the following settings:
o Name: LabAutomationAccount
o Resource group: create a new resource group named AutomationLabRG
o Region: an Azure region that you chose when running the provisioning script
o Account Options: leave at the default setting. This will create a tutorial runbook in the new
account
o Pin to dashboard: Leave enabled
4. Wait for the Automation account to be provisioned. This should take less than a minute.
 Task 2: Create an Azure AD user

1. From the Azure classic portal, create a new user in the default directory of your Azure subscription,
o USER NAME: LabAutomationUser
o ROLE: user
o Multi Factor Authentication: disabled
o DISPLAY NAME: Lab Automation User
2. From the Azure classic portal, configure the new user as a Co-Administrator of the current
subscription.
3. Change the temporary password of the newly created user to Pa$$w0rd.
 Task 3: Create Automation assets

1. In the Azure portal, in the Automation Account blade, add a Credential asset:
o Name: PSCredential
o Description: Lab Automation User (Co-Administrator)
2. In the same Automation account, create the following Automation unencrypted Variable assets of the
String type:
o SubscriptionName: name of your subscription
o AdminName: Student
o AdminPassword: Pa$$w0rd
o Location: the name of Azure region that you used when running the provisioning script at the
beginning of this module
o Network: ADATUM-HQ-VNET
o Subnet: Subnet-1
3. In the same Automation account, create the following Schedule asset:
o Name: EndOfDay
o Recurrence: Daily
o Expires: Never
Results: After completing this exercise, you should have configured a new Microsoft Azure Automation
account, and created a new Microsoft Azure Active Directory (Azure AD) organizational account to use as
an Automation Credential asset.
Exercise 2: Creating runbooks

Scenario
As part of your tests of the new Azure Automation features, you will now deploy Azure virtual machines
by using an Automation runbook.
1. Import a runbook.
2. Publish and execute a runbook.
 Task 1: Import a runbook

1. From the Azure portal, import the PowerShell workflow script New-StorageVNetAndVMs.ps1
residing in the D:\Labfiles\Lab11\Solution folder into your Automation account.
2. Review the content of the runbook.
 Task 2: Publish and execute a runbook

1. Publish the New-StorageAndVMs runbook.
2. Start the newly published runbook.
3. View the progress of the runbook execution. Wait until the job completes.

Reset-Azure
subscription.

Note: This script will remove Azure services in your subscription. We therefore recommend
that you use an Azure trial pass that was provisioned specifically for this course, and not your
own Azure account.
The script will take 5-10 minutes to reset your Microsoft Azure environment to be ready for the
next lab.
(if this occurs, you will see an error). If you find remaining objects after the reset script is
complete, you can rerun the Reset-Azure script, or use the Azure portal and Azure classic portal
to delete all the objects in your Azure subscription manually —with the exception of the default
director.
Results: After completing this exercise, you should have imported, published, and executed a PowerShell
workflow–based runbook that deploys two virtual machines in parallel.
Question: Why did you have to create an Azure AD account in the lab?
Question: What should you consider when testing the execution of an Automation
runbook?

Review Question
Question: What are the potential benefits and challenges of running PowerShell workflows
from an on-premises computer as compared to running them as Azure Automation
runbooks?
Course Evaluation
Your evaluation of this course will help Microsoft understand the quality of your learning experience.
Please work with your training provider to access the course evaluation form.
Microsoft will keep your answers to this survey private and confidential and will use your responses to
improve your future learning experience. Your open and honest feedback is valuable and appreciated.
L1-1
Module 1: Introduction to Microsoft Azure

Lab: Managing Microsoft Azure
Exercise 1: Using the Azure portals
 Task 1: Use the Azure classic portal
1. Ensure that you are signed in to the 20533C-MIA-CL1 virtual machine as Student with the password
Pa$$w0rd. You should have already run the preparation script in the “Preparing the environment”
demonstration at the beginning of the module.
2. On the taskbar, click the Internet Explorer shortcut.
3. In Internet Explorer, in the address bar, type https://manage.windowsazure.com, and then press
Enter.
4. On the Microsoft Azure sign in page, enter the email address with which your Azure account is
associated, and then click Continue.
5. On the Sign in page, type the email address and password you set up for this course, and then click
Sign in.
6. On the Azure classic portal page, in the navigation bar, scroll down, and then click SETTINGS.
7. On the settings page, click ADMINISTRATORS, and then at the bottom of the pane, click ADD.
8. In the EMAIL ADDRESS box, type a random email address ending with @outlook.com, select the
check box to select the free trial subscription, and then click the check mark icon.
Note: Observe that the email address you typed is now listed as the co-administrator. An
email containing an invitation to act as co-administrator has been sent to this email address.
9. On the Azure classic portal page, in the navigation bar, click ACTIVE DIRECTORY.
10. In the active directory pane, click Default Directory. This is the default Azure Active Directory (Azure
AD) instance for your subscription.
11. On the Let’s talk about Azure AD page, deselect all checkboxes and then click the check mark at the
bottom of the page.
12. On the Default Directory page, click USERS. Note the two accounts that are listed: your account and
the co-administrator account you created earlier.
13. On the Default Directory page, click DOMAINS. Note the name of the default domain for your
subscription displayed in the Default Directory pane.
L1-2 Introduction to Microsoft Azure
 Task 2: Use the Azure portal

1. In Internet Explorer, on the Azure classic portal page, at the top of the screen, click Check out the
new portal, and then click Launch. If you do not have the Azure classic portal open, go to
2. On the Dashboard page, at the top of the screen, click Edit dashboard.
3. On the Dashboard page, on the All resources tile, click the ellipses (…), and then click 4x6.
4. On the Dashboard page, on the Service health tile, click the ellipses (…), and then click 2x4.
5. On the Dashboard page, at the top of the screen, click Done customizing.
6. On the Dashboard page, on the Hub menu, click Browse, and then click the star beside Storage
accounts.
 Task 3: Use the account page of the Azure portal

1. In Internet Explorer, in the address bar, type https://account.windowsazure.com, and then press
Enter.
2. On the Account page, click SIGN IN.
3. On the Sign in page, type the email address and password you set up for this course, and then click
Sign in.
4. On the Account portal page, click subscriptions.
5. On the subscriptions page, click the subscription you are using for this course. View the billing
summary for your subscription on the page.
6. On the subscriptions page, on the right side of the screen, click Download usage details.
7. On the Summary for Azure Pass page, click Download Usage, and then click Version 1.
8. In Internet Explorer, when prompted whether to open or save the .csv file, click Open.
9. When prompted, How do you want to open this file?, click Notepad and then click OK.
10. View the contents of the file in Notepad. Note that this is intended to simply review its content—
typically to analyze it in more details, you would use Microsoft Excel or other program capable of
parsing .csv files.
11. Close Notepad.
12. On the Account portal page, click Preview features.
13. On the Preview features page, find a preview feature and click try it now.
14. In the Add Preview Feature window, click the check mark to approve the preview feature. After the
window closes, note the status of the feature (You are queued).
Results: After completing this exercise, you will have used the Azure portals.
Implementing Microsoft Azure Infrastructure Solutions L1-3
Exercise 2: Using the Azure Resource Manager features in the Azure portal
 Task 1: Create and manage a resource group
1. In Internet Explorer, in the address bar, type https://portal.azure.com, and then press Enter.
2. In the Azure portal, click Resource groups.
3. On the Resource groups blade, click Add.

4. On the Resource groups blade, type the following values, and then click Create:
o Resource group name: TestRG1
o Subscription: leave as the default
o Resource group location: your preferred location
 Task 2: Create Azure resources

1. On the Azure portal page, click New, click Data + Storage, and then click Storage account.
2. On the Create storage account blade, in the Name box, type a unique name for the storage account
you are creating. You can use the current date and your initials to create a unique value in the format
storageMMDDYYYYab.
Note: For example, a student named Ed Meadows might use storage04252016em.

All alphabetical characters must be lowercase.
3. In the Resource Group section, click the drop-down box, and then click TestRG1.
4. In the Location list, select the location you have been using for the course, and then click Create.
Note the progress of the storage account creation on the dashboard. Wait until the creation is
complete before moving to the next task.
 Task 3: Configure tagging

1. In the Azure portal, on the Hub menu, click Resource groups.
2. On the Resource groups blade, click TestRG1, and then in the Settings blade for TestRG1, click
Tags.
3. On the Tags blade, in the Key box, type project, and then in the Value box, type Test. Click Save.
4. On the TestRG1 blade, click storageDDMMYYYYab, and then in the upper-right area of the
storageDDMMYYYYab pane, click the Tags icon.
5. In the Tags pane, in the Key box, type project. In the Value box, type Test. Click Save.
6. In the Tags pane, click the ellipses (…) next to project: Test, and then click Pin to dashboard.
7. On the Azure portal page, in the upper left, click Microsoft Azure to go to the Dashboard page.
8. On the Dashboard page, click the project:Test tile. View the resources associated with this tag.
 Task 4: Configure RBAC

1. On the Azure portal page, in the upper left, click Microsoft Azure to go to the Dashboard page.
2. On the Hub menu, click Resource groups, and then click TestRG1.
3. On the Settings blade for TestRG1, under Resource Management, click Users.
4. On the Users blade, click Roles, and then on the Roles pane, click Storage Account Contributor.
5. In the Storage Account Contributor blade, click Add, and then in the Add users blade, click the
user you added earlier in the lab. Click Select.
6. Scroll to the Users blade, and then note that the user has been added to the user list as a Storage
Account Contributor.
Results: After completing this exercise, you will have used the Azure Resource Manager features in the
Azure portal.
Exercise 3: Using Azure PowerShell

 Task 1: Connect Azure PowerShell to your Azure subscription
1. On MIA-CL1, on the taskbar, click Start, type ISE, and then click Windows PowerShell ISE.
2. In the Windows PowerShell Integrated Scripting Environment (ISE), at the command prompt, type the
following command, and then press Enter:
3. In the sign-in windows that appears, sign in to your Azure account.
then press Enter:
then press Enter:
Get-AzureRmResourceProvider
6. View the Azure resource providers, resource types, and the Azure regions where these resources are
available.
 Task 2: Manage Azure services and resource groups

1. In the Windows PowerShell ISE window, open the D:\Labfiles\Lab01\Starter\Lab01Starter.ps1 file.
2. In the #Variables section, modify the $locName variable to match the Azure location that your
instructor asked you to use.
3. In the #Variables section, modify the $webappName variable to a unique name by using the current
date and your initials in the TestWebAppMMDDYYAB format.
4. Under the line that starts: #Create a web app, type the following code:
New-AzureRmWebApp –Name $webappName –ResourceGroupName $rgname –Location $locName

5. Select all of code in the file, including the line you just typed, right-click it, and then click Run
selection.
6. In the Windows PowerShell ISE window, at the command prompt, type the following command and
then press Enter:
Get-AzureRmResource | Where {$_.ResourceGroupName -eq $rgName}
7. View the list of resources that belong to the TestRG1 resource group.
8. In the Windows PowerShell ISE window, at the command prompt, type the following command and
then press Enter:
New-AzureRMResourceGroup –Name $newrgname –location $locname
9. In the Windows PowerShell ISE window, in the script pane, under the line that starts with #Move the
web app, type the following code, and then press Enter:
$resource = Get-AzureRmResource -ResourceName $webappname -ResourceGroupName $rgname

Move-AzureRmResource -DestinationResourceGroupName $newrgname -ResourceId
$resource.ResourceId
10. Select the code in step 9, right-click it, and then click Run Selection.
11. In the Confirm window, click Yes.
12. In the Windows PowerShell ISE window, at the command prompt, type the following code, and then
press Enter:
Get-AzureRmResource | Where {$_.ResourceGroupName -eq $newrgName}
13. View the web app you created earlier, which is now in the TestWebRG resource group.

1. Close all open apps without saving any files.
Reset-Azure
subscription.

Azure account.
Results: After completing this exercise, you will have used Azure PowerShell to create and manage Azure
resources.
L2-7
Module 2: Implementing and managing Azure networking

Lab A: Using a deployment template and
Azure PowerShell to implement Azure
virtual networks
Exercise 1: Creating an Azure virtual network by using a deployment
template
 Task 1: Access the template on GitHub
1. Ensure that you are signed in to MIA-CL1 as Student with the password Pa$$w0rd.
2. On the desktop, on the taskbar, click the Internet Explorer icon.
3. In the Microsoft Internet Explorer Address bar, type the following address, and then press Enter:
http://aka.ms/Mt32e4.
4. Open a GitHub template that you can use to create a virtual network with two subnets.
 Task 2: Load the template into new deployment on the Azure portal
1. In Internet Explorer, under Virtual Network with two Subnets, click Deploy to Azure.
2. When prompted, sign in using the Microsoft account associated with your Azure subscription.
3. In the Azure portal, in the Custom deployment blade, click the Edit Template link.
4. Review the structure of the JavaScript Object Notation (JSON) file. Examine the placeholders for
values that can be edited during the deployment. This template contains the following parameters
that you can edit: location, vnetName, vnetAddressPrefix, subnet1Name, subnet1Prefix, subnet2Name,
subnet2Prefix.
5. Review the content under resources to identify type of the resource, its name, and properties.
6. Click Discard to close the Edit Template blade.
Note: If the template fails to load into the Azure portal, navigate to the following URL:
http://aka.ms/Fpqovq. Then, select and copy all the text. Paste the copied text into the Edit
Template blade, and then perform steps 4 and 5 to review the template.
 Task 3: Run the deployment from the Azure portal

1. In the Custom Deployment blade click Edit Parameters.
2. Type the following information for the Parameters, and then click OK.
o VNETNAME: HQ
o VNETADDRESSPREFIX: 10.0.0.0/16
L2-8 Implementing and managing Azure networking
3. In the Custom Deployment blade, under the Resource Group section, from the drop-down list
select New. In the New resource group name field, type AdatumLabRG to create a new Resource
group with that name.
4. In the Custom Deployment blade under the Resource group location drop-down list, select
<Location1>.
5. In the Custom Deployment blade, click the Legal Terms link. Review the Terms of use, and then
click Purchase.
6. In the Custom Deployment blade, click Create to create the new virtual network.
7. Verify that provisioning of the new virtual network with name HQ completed successfully.
Results: After completing this exercise, you should have created virtual networks for A. Datum HQ.
Exercise 2: Creating a virtual network by using PowerShell

 Task 1: Create a virtual network by using PowerShell
1. From the taskbar, start Windows PowerShell.
2. Sign in to your subscription by typing the following command, and then pressing Enter:
3. To select the subscription in which you are going to create a virtual network, type the following
commands, and then press Enter after each (replace ‘Name of your subscription’ with the actual name
of your subscription and make sure to enclose the name of your subscription in single quotes):
4. To create a new resource group, type the following command, and then press Enter (replace
‘Location’ with the actual name of the primary Azure region provided by the instructor and make sure
to enclose the name of the region in single quotes):
New-AzureRMResourceGroup –Name AdatumTestRG –Location ‘Location1’
5. To create a new virtual network named AdatumTestVnet with the address space 10.0.0.0/16 and
store a reference to it in the $vnet variable, type the following command, and then press Enter
(replace ‘Location’ with the actual name of the primary Azure region provided by the instructor and
make sure to enclose the name of the region in single quotes):
$vnet = New-AzureRMVirtualNetwork –ResourceGroupName AdatumTestRG –Name AdatumTestVnet

–AddressPrefix 10.0.0.0/16 –Location ‘Location1’
6. To add a subnet to the new virtual network, type the following command, and then press Enter:

7. To update the configuration in the virtual network, type the following command, and then press
Enter:
Results: After completing this exercise, you should have created a test virtual networks for A. Datum by
using Azure PowerShell.
Exercise 3: Configuring virtual networks

 Task 1: Create an IaaS v1 virtual network gateway
1. Switch to Internet Explorer and in the new tab navigate to open the classic Azure portal by typing
http://manage.windowsazure.com.
Azure subscription.
VNET.
5. From the command bar located at the bottom of the page, click CREATE GATEWAY and then select
Dynamic Routing.
6. Click Yes to confirm creation of a VPN gateway.
Note: The creation of the VPN gateway could take 30 - 35 minutes to complete.
 Task 2: Deploy an IaaS v2 virtual machine into an IaaS v2 virtual network

1. Right-click Windows PowerShell shortcut in the taskbar and click Run ISE as Administrator.
press Enter:
.\CreateVirtualMachine.ps1
Note: The command starts with dot backslash.
4. When prompted to sign in (twice), type in the user name and the password which is either the Service
Administrator or a Co-Admin in your Azure subscription.
5. If you have multiple subscription, when prompted, type in the number corresponding to the
subscription to which you deployed the virtual network in the first exercise of this lab and press Enter.
Note: The script takes about 10 minutes to complete.
The script deploys an IaaS v2 virtual machine named ARMSrv2 onto the first subnet of the IaaS v2 HQ
virtual network you provisioned earlier in this lab.
Results: After completing this exercise, you should have created a virtual network gateway on the existing
IaaS v1 virtual network and deployed a virtual machine to the newly created IaaS v2 HQ virtual network.
Lab B: Configuring connectivity between

IaaS v1 and IaaS v2
Exercise 1: Using a PowerShell script to connect IaaS v1 VNet and
IaaS v2 VNet
 Task 1: Configure Resource Manager virtual network
1. On MIA-CL1, launch Internet Explorer and browse to the classic Azure portal by typing
http://manage.windowsazure.com.
Azure subscription.
VNET.

5. Ensure that the provisioning of the new virtual gateway that you started in the first lab of this module
has been completed. You can determine this by checking whether DELETE GATEWAY button
appears in the command bar at the bottom of the page. If it is there, the gateway provisioning has
completed. If not, wait until icon appears in the command bar. You might need to occasionally
refresh the page. Keep in mind that provisioning can take about 30-35 minutes.
6. On MIA-CL1, from the Azure PowerShell window, set the current directory to
D:\Labfiles\Lab02\Starter by typing:
7. Open the ConfigureARMGateway.ps1 file in Notepad and review its content.
8. From the Azure PowerShell window, run ConfigureARMGateway.ps1 by typing the following
command, and then pressing Enter:
.\ConfigureARMGateway.ps1
9. When prompted to sign-in (twice), use an account that is either a Service Admin or a co-admin of
your Azure subscription.
10. Occasionally monitor the execution status.
Note: The script might take 20-25 minutes to complete. You do not have to wait for the
script to finish. You can proceed with second task of this exercise and with Exercise 2 from this
lab.
 Task 2: Configure classic virtual network

1. On MIA-CL1, launch Internet Explorer and browse to the Azure Portal at https://portal.azure.com.
2. If prompted, sign in to your Azure subscription when prompted with an account that is a Service
admin or a co-admin of your subscription.
3. In the Azure portal, in the Hub menu, click Browse, scroll down towards the bottom of the list of
services and click Virtual networks.
4. In the Virtual networks blade, click HQ.

5. In the HQ blade, in the Connected devices section, take the note of the value in the IP ADDRESS
column for gatewayARM.
6. On MIA-CL1, launch File Explorer and browse to the D:\Configfiles\Lab02 folder.
7. Right-click on the NetworkConfig.xml file and click Open with in the menu.
8. In the next cascading menu, click Notepad in the list of programs.

9. In Notepad, under the LocalNetworkSite section, modify the value of <VPNGatewayAddress>
(which is at this point set to 1.1.1.1) by replacing 1.1.1.1 with the value of the IP address that you
recorded in step 5, save the changes to NetworkConfig.xml, and then close the file.
10. On MIA-CL1, launch Windows PowerShell as Administrator by using the taskbar icon.
11. At the Windows PowerShell prompt, sign into your Azure subscription by running:
Add-AzureAccount
12. If you have multiple subscriptions, to select the target subscription, type the following commands,
and then press Enter after each (replace ‘Name of your subscription’ with the actual name of your
subscription and make sure to enclose the name of your subscription in single quotes):
Get-AzureSubscription
Set-AzureSubsciption –SubscriptionName ‘Name of your subscription’
Set-AzureVNetConfig -ConfigurationPath D:\Configfiles\Lab02\NetworkConfig.xml
14. To set the IPSec shared key for the classic VNet gateway, type the following command at the
Windows PowerShell command prompt, and then press Enter:
Set-AzureVNetGatewayKey –VnetName Adatum-Branch-Vnet –LocalNetworkSiteName HQ

–SharedKey 12345
15. Wait for the command to complete and display the StatusCode OK.
16. Open Internet Explorer.
17. In Internet Explorer, browse to the classic Azure Management Portal at

https://manage.windowsazure.com, and, if prompted, sign in using the Microsoft account that is
either the Service Admin or a co-Admin of your subscription.
18. Click NETWORKS in the navigation bar on the left hand side.
19. On the networks page, click, ADATUM-BRANCH-VNET.

21. On the DASHBOARD page, verify that the ADATUM-BRANCH-VNET and HQ are connected. You
might need to click CONNECT in the menu bar or refresh the Internet Explorer page.
22. Leave the Internet Explorer window open.
Results: After completing this exercise, you should have connected the A. Datum HQ and branch virtual
networks, and deployed dynamic routing gateways for each virtual network.
Exercise 2: Configuring a point-to-site VPN

 Task 1: Configure a VPN from a client to the headquarters virtual network
1. In Internet Explorer, on the adatum-branch-vnet page, click CONFIGURE.
2. Select the Configure point-to-site connectivity check box.
3. In the STARTING IP text box, type 172.16.0.0, and then set the CIDR (ADDRESS COUNT) to
/24 (254).
4. At the bottom of the page, click SAVE.
5. In the warning message, click Yes.

6. Press the Windows logo key, and then type Command.
7. Right-click Command Prompt, and then click Run as administrator.

9. At the Command Prompt, type the following command, and then press Enter:
CD C:\Program Files (x86)\Windows Kits\10\bin\x64
makecert -sk exchange -r -n "CN=AdatumRootCertificate" -pe -a sha1 -len 2048 -ss My

12. On the adatum-branch-vnet page, click CERTIFICATES.
13. Click UPLOAD A ROOT CERTIFICATE.
14. In the Upload Certificate dialog box, click BROWSE FOR FILE.
15. In the Choose File to Upload dialog box, navigate to C:\Program Files (x86)\Windows Kits
\10\bin\x64, select AdatumRootCertificate, and then click Open.
16. In the Upload Certificate dialog box, click the check mark icon.
17. Switch back to the Command Prompt window.
makecert.exe -n "CN=AdatumClientCertificate" -pe -sk exchange -m 96 -ss My -in

20. Press the ALT key, click Tools, and then click Internet Options.
21. In Internet Options, click the Content tab, and then click Certificates.
22. Verify that both the AdatumClientCertificate and AdatumRootCertificate display in the Personal
store.
23. Close Certificates.
24. Close Internet Options.

 Task 2: Connect to the HQ virtual network

1. Switch back to the Internet Explorer tab with the classic portal.
2. On the adatum-hq-vnet page, click DASHBOARD.
3. In the quick glance section, click Download the 64-bit Client VPN Package.
4. When prompted whether to save or run the file, click Run.
5. In the Windows protected your PC dialog box, click More Info, and then click Run anyway.
7. In the ADATUM-BRANCH-VNET dialog box, click Yes.
8. In the Search the web and Windows text box, type ncpa.cpl and press Enter.
9. In the Network Connections window, right-click ADATUM-BRANCH-VNET, and then click
Connect/Disconnect. This will launch the Settings app with the VPN tab of NETWORK & INTERNET
page.
10. Click ADATUM-BRANCH-VNET, and then click Connect. This will open the ADATUM-BRANCH-
VNET dialog box.
11. Click Connect again.
12. When prompted to accept that the Connection Manager needs elevated privileges to run
CMROUTE.DLL, click Continue.
13. After the connection is established, switch back to the Command Prompt window.
ipconfig /all
15. In the results, verify that there is a PPP adapter ADATUM-BRANCH-VNET section, and that you have
an assigned IP address from the IP address range you defined for the point to site connectivity
(172.16.0.0/24).
16. In the Search the web and Windows textbox in the taskbar of MIA-CL1, type the following and press
Enter:
Mstsc /admin /f /v:192.168.0.4
17. If prompted whether to connect, click Yes.
18. In the Windows Security dialog box, enter the following credentials, and then click OK:

19. If prompted again whether to connect, click Yes.
20. This will establish a Remote Desktop session to the private IP address of ClassicSrv1 Azure virtual
machine. Verify that you can successfully log on to ClassicSrv1.
Note: Note that you could potentially also test connectivity to a file share on ClassicSrv1
Azure virtual machine or ping it by its IP address, however, that would require modifying
Windows Firewall settings on ClassicSrv1 in order to allow File and Printer Sharing traffic.
21. Close the Remote Desktop session.

22. Switch back to the VPN tab of the NETWORK & INTERNET page of the Settings app.
23. Click Disconnect, next to the ADATUM-BRANCH-VNET entry.
Results: After completing this exercise, you should have configured and tested a point-to-site VPN
connection.
Exercise 3: Validating virtual network connectivity

 Task 1: Connect to the A. Datum VMs
1. On MIA-CL1, open Internet Explorer and navigate to the Azure classic portal at
2. In the Azure classic portal, click VIRTUAL MACHINES in the navigation bar on the left side of the
window.
3. Make sure that ClassicSrv1 is selected, and then click CONNECT in the menu bar at the bottom of
the window.
4. When prompted whether to open or save the .rdp file, click Open.
5. If a Remote Desktop Connection warning message displays, select Don’t ask me again for
connections to this computer, and then click Connect.
6. In the Windows Security dialog box, type the following credentials, and then click OK:

7. If another Remote Desktop Message displays, select Don’t ask me again for connections to this
computer, and then click Yes.
8. Minimize the ClassicSrv1 RDP session.
9. From MIA-CL1, launch Internet Explorer and navigate to the Azure portal at
10. In the Azure portal, click Browse in the Hub menu on the left hand side of the window and click
Virtual machines.
11. On the Virtual machines blade, click ARMSrv2.
12. On the ARMSrv2 blade, click Connect in the toolbar.
13. When prompted whether to open or save the .rdp file, click Open.
15. In the Windows Security dialog box, type the following credentials, and then click OK:
 Task 2: Test TCP/IP connectivity between the sites

1. From the ARMSrv2 RDP session, if prompted whether to enable network discovery, click No.
2. In Server Manager, click Local Server.
3. If the status of Windows Firewall is On for the Public profile, click Public:On.
4. In Windows Firewall, click Turn Windows Firewall on or off.
5. Under Public network settings, click Turn off Windows Firewall (not recommended), and then
click OK.
6. Close the Windows Firewall window.
7. Minimize the ARMSrv2 RDP session.
8. Maximize the ClassicSrv1 RDP session.
9. If prompted whether to enable network discovery, click No.
10. In Server Manager, click Local Server.

11. If the status of Windows Firewall is On for the Public profile, click Public:On.
12. In Windows Firewall, click Turn Windows Firewall on or off.
13. Under Public network settings, click Turn off Windows Firewall (not recommended), and then
click OK.
14. Close the Windows Firewall window.
15. In the ClassicSrv1 RDP session, on the taskbar, click the Windows PowerShell icon.
Ping 10.0.0.4
17. Verify that ARMSrv1 responds to Internet Control Message Protocol (ICMP) messages.

Reset-Azure

not your own Azure account. The script will take 5-10 minutes to reset your Microsoft Azure
environment, and ready it for the next lab. The script removes all storage, virtual machines (VMs),
virtual networks and gateways, cloud services, and resource groups.
directory.
Results: After completing this exercise, you should have verified that VMs can communicate between the
virtual networks.
L3-19

Lab A: Creating IaaS v2 virtual machines
in Azure
Exercise 1: Creating virtual machines by using the Azure portal and Azure
PowerShell
 Task 1: Use the Azure portal to create a virtual machine
1. On MIA-CL1, in Internet Explorer, in the address bar, type https://portal.azure.com, and then press
Enter.
your subscription.
3. On the Hub menu, click Virtual machines, and then, on the Virtual machines blade, click Add.
4. On the Virtual Machines blade, click Windows Server.

5. On the Windows Server blade, click Windows Server 2012 R2 Datacenter, and then on the
Windows Server 2012 R2 Datacenter blade, ensure that Resource Manager appears in the Select
a deployment model list box, and then click Create.
6. On the Basics blade, specify the following:
o Name: ResDevDB1
7. In the Resource group section, click the drop-down list and click ResDevRG.
8. Accept the default Location value and click OK.
9. On the Choose a size blade, click A1Standard, and then click Select.
10. On the Settings blade, ensure that HQ-VNET is selected as the Virtual network.
11. Click Subnet.
12. On the Choose subnet blade, click Database.
13. On the Settings blade, click OK.
14. On the Summary blade, click OK.
Note: You can monitor the virtual machine’s deployment progress on the Dashboard page.
 Task 2: Use Azure PowerShell to create a virtual machine

1. On MIA-CL1, click the Start button, type ISE, and then click Windows PowerShell ISE.
2. In the Windows PowerShell Integrated Scripting Environment (ISE) window, open the
CreateRmVM.ps1script at D:\Labfiles\Lab03\Starter\.
3. In the Windows PowerShell ISE window, review the content of the script.
4. In the Windows PowerShell ISE, click the Run Script icon or press F5.
L3-20 Implementing virtual machines
5. In the Sign into your account window, type the name and password of an account that is either the
Service Administrator or Co-administrator of your Azure subscription, and then click Sign in.
6. If you have multiple subscriptions, select the one to use in the labs in this module.
7. When the script is complete, leave the Windows PowerShell ISE window open.
Results: After completing this exercise, you will have created virtual machines by using the Azure portal
and Azure PowerShell.
Exercise 2: Validating virtual-machine creation

 Task 1: Use Azure PowerShell to validate virtual-machine deployment
1. In the Windows PowerShell ISE window, at the command prompt, type the following command, and
then press Enter:
Get-AzureRmResource | where {$_.ResourceType –like “*VirtualMachines”}
2. Confirm that the ResDevDB1 and the ResDevDB2 virtual machines are listed. Note that both virtual
machines belong to the ResDevRG resource group.
 Task 2: Use the Azure portal to validate virtual-machine deployment

1. On MIA-CL1, switch to Internet Explorer.
2. In the Internet Explorer window, in the Azure portal, on the Hub menu, click All resources.
Note: Note that both ResDevDB1 and ResDevDB2 are listed, along with the network and
storage resources that you created in the previous exercise.
3. On the Hub menu, click Virtual machines.

4. On the Virtual machines blade, click ResDevDB1.
5. On the ResDevDB1 blade, confirm the following values:
o Resource group: ResDevRG
o Virtual network/subnet: HQ-VNET/Database
6. Repeat steps 4 and 5 for the ResDevDB2 virtual machine.
Results: After completing this exercise, you will have validated the creation and configuration of Azure
Virtual Machines.
Lab B: Deploying IaaS v2 virtual machines

by using Azure Resource Manager
templates
Exercise 1: Using Visual Studio and an Azure Resource Manager template
to deploy IaaS v2 virtual machines
 Task 1: Use Visual Studio to deploy the Linux app server’s virtual machines
1. On MIA-CL1, on the taskbar, click the Visual Studio icon.
2. In Visual Studio, click File, click Open, click Project/Solution, and then browse to
D:\Labfiles\Lab03\Starter\ResDev\ResDevLinuxDeploy.
3. In the Open Project window, click ResDevLinuxDeploy.sln, and then click Open.
4. In Visual Studio, in the Solution Explorer pane, expand Templates, and then click azuredeploy.json.
5. View the parameters and variables section of the template.
6. In the Solution Explorer pane, right-click ResDevLinuxDeploy, click Deploy, and then click New
Deployment.
7. If necessary, in the Deploy to Resource Group window, click Add an account. In the Sign in to your
account window, sign in with an account that is either the Service Administrator or Co-administrator
8. In the Deploy to Resource Group window, click the Resource Group drop-down box, and then click
ResDevRG.
9. In the Deploy to Resource Group window, click Edit Parameters.
10. In the Edit Parameters window, populate the parameter values according to details in the following
list:
o resourceGroupName: ResDevRG
o subnetName: App
o vmSize: Standard_D1
o ubuntuOSVersion: 14.04.2-LTS
o storageAccountType: Standard_LRS
11. In the Edit Parameters window, click the Save passwords check box, and then click Save.
12. In the Deploy to Resource Group window, click Deploy.
Note: Deployment will run with the output that appears in the Output pane, which is at
the bottom of the window. When deployment is complete, you will receive a message stating the
13. In the Solution Explorer pane, click Azuredeploy.parameters.json.
In the main window pane, notice that the parameters that you entered in the first deployment are
saved in this file. You can reuse these parameters for the deployment of the second app server.
14. In the Solution Explorer pane, right-click ResDevLinuxDeploy, click Deploy, and then click
ResDevRG.
15. In the Deploy to Resource Group window, click Edit Parameters.
16. In the Edit Parameters window, in the vmName Value box, type ResDevApp2, and then click Save.
17. In the Deploy to Resource Group window, click Deploy.
Note: Deployment will run with the output that appears in the Output pane, which is at
the bottom of the window. When deployment is complete, you will receive a message stating the
18. In the Visual Studio, click File and then on the drop-down menu, click Close Solution.
19. Leave Visual Studio open.
 Task 2: Use Azure PowerShell to validate the deployment of the app server’s virtual
machines
1. On MIA-CL1, on the taskbar, right-click the Windows PowerShell icon and select Run ISE as
Administrator from the pop-up menu.
2. In the Windows PowerShell ISE, at the command prompt, type the following cmdlet, and then press
Enter:
3. When prompted, sign in to your Azure subscription with an account that is either the Service
Administrator or Co-administrator of your Azure subscription.
4. If you have multiple subscriptions associated with your account, at the Windows PowerShell ISE
prompt, type the following cmdlet, and then press Enter:
5. Identify the name of the Azure subscription to which you deployed virtual machines in the previous
task of this exercise, type in the following cmdlet, and then press Enter (replace ‘Name of your
subscription’ with the actual name of your subscription and make sure to enclose the name of your
subscription in single quotes):
6. Type the following cmdlet, and then press Enter:
Find-AzureRMResource –ResourceGroupNameContains ResDevRG | Format-Table –Property

ResourceName, ResourceType
7. In the cmdlet output, note the resources created in this exercise: ResDevApp1 and ResDevApp2
virtual machines, and an NIC, public IP, and storage account for each virtual machine.
8. Leave the Windows PowerShell ISE window open for the next exercise.
Results: After completing this exercise, you will have deployed Azure Virtual Machines by using Visual
Studio and an Azure Resource Manager template.
Exercise 2: Using Azure PowerShell and an Azure Resource Manager

template to deploy virtual machines
 Task 1: Use Azure PowerShell to deploy the Windows virtual machines
1. In the Windows PowerShell ISE window that you opened in the previous exercise, click File, and then
click Open.
2. In the Open dialog box, navigate to the D:\Labfiles\Lab03\Starter\ResDev folder.
3. Click ResDevWindowsDeploy.ps1, and then click Open.
4. In the Windows PowerShell ISE window, review the script that will initiate the template.
Note: Note the $templateFile and $rgName variables. These represent the location of the
Azure Resource Manager template file and the resource group to which you will deploy the
virtual machines.
5. Switch to Visual Studio and click File, click Open, and then click File.
6. In the Open File dialog box, navigate to the D:\Labfiles\Lab03\Starter\ResDev folder.

7. Click ResDevWindowsDeployTemplate.json, and then click Open.
Note: Note that the template has the same structure as the template for the Linux virtual
machines in the previous exercise. The only difference between the two templates is the variables
declaring the image and operating system details.
9. Switch back to the Windows PowerShell ISE window and run the ResDevWindowsDeploy.ps1 script.
When prompted, provide the following values for the parameter prompts, pressing Enter after each
value:
o vmName: ResDevWeb1
o subnetName: Web
10. When the script completes, repeat step 9, changing only the value of the vmName parameter to
ResDevWeb2.
 Task 2: Use the Azure portal to validate deployment of the Windows virtual
machines
1. In Internet Explorer, on the address bar, type https://portal.azure.com, and then press Enter.
your subscription.
3. On the Hub menu, click Resource groups.
4. On the Resource groups blade, click ResDevRG.

5. On the ResDevRG blade, in the Summary section, view the Resource list. Click the ellipsis (…) in the
lower-right corner to see all of the resources in this resource group.
Note: Note the virtual machines and the NIC and public IP resources for each virtual
machine.
6. On the Resources blade, click ResDevWeb1.
7. On the ResDevWeb1 blade, in the Essentials section, note that ResDevWeb1 has been assigned to
the HQ-VNet/Web virtual network/subnet, and the operating system is Windows.

Reset-Azure

The script will take 5-10 minutes to reset your Microsoft Azure environment, and prepare it for
the next lab.
groups.
(you will see an error, if this occurs). If you still find objects after the reset script is complete, you
can rerun the Reset-Azure script, or use the full Azure portal to manually delete all the objects in
your Azure subscription, with the exception of the default directory.
Results: After completing this exercise, you will have deployed Azure Virtual Machines by using Windows
PowerShell and a Resource Manager template.
L4-27
Module 4: Managing virtual machines

Lab: Managing Azure virtual machines
Exercise 1: Configuring availability
 Task 1: Create virtual machines in an availability set
1. On MIA-CL1, open Internet Explorer and navigate to the Azure portal at https://portal.azure.com.
subscription you are using for this lab.
3. On the Hub menu, click +New. In the New blade, in the Search the marketplace text box, type
Availability Set, and press the Enter keyboard key.
4. In the Everything blade, select Availability Set.
5. In the Availability Set blade, click Create.
6. In the Create availability set blade, specify the following settings:

o Name: ResDevWebAS
o Fault domains: 3
o Update domains: 5
o Resource group name: ResDevWebAS
o Location: The Azure region closest to the location of your lab computer.
7. Click Create. Wait for deployment to complete. This should take only a few seconds.
8. On the Startboard of the Azure portal, click +New on the Hub menu.
9. In the New blade, click Virtual Machines.
10. In the Virtual Machines blade, click Windows Server 2012 R2 Datacenter.
11. In the Windows Server 2012 R2 Datacenter blade, ensure that Resource Manager appears in the
Select a deployment model drop-down list, and then click Create. The Create virtual machine
blade appears and expands its Basics blade.
12. In the Basics blade, specify the following:
L4-28 Managing virtual machines
13. Click OK. The Choose a size blade automatically appears.
14. In the Choose a size blade, select A1 Standard, and then click Select. The Settings blade appears.
15. In the Settings blade, specify the following settings:


16. Click OK. The Summary blade automatically appears.
17. In the Summary blade, click OK.
18. On the Startboard of the Azure portal, click +New on the Hub menu.
19. In the New blade, click Virtual Machines.
20. In the Virtual Machines blade, click Windows Server 2012 R2 Datacenter.
21. In the Windows Server 2012 R2 Datacenter blade, ensure that Resource Manager appears in the
Select a deployment model drop-down list, and then click Create. The Create virtual machine
blade appears and expands its Basics blade.
22. In the Basics blade, specify the following:
23. Click OK. The Choose a size blade automatically appears.
24. In the Choose a size blade, select A1 Standard, and then click Select. The Settings blade
automatically appears.
25. In the Settings blade, specify the following settings:

26. Click OK. The Summary blade automatically appears.
27. In the Summary blade, click OK.
28. On the Startboard of the Azure portal, click Browse on the Hub menu.
29. In the list of services, select Availability sets.

30. On the Availability sets blade, click ResDevWebAS.
31. On the ResDevWebAS blade, note that the availability set contains the two newly deployed virtual
machines (at this point, both of them will likely display the Creating status). Point out that each VM
has a unique fault domain and update domain.
32. Leave the instance of Internet Explorer with the Azure portal open.
 Task 2: Configure the Azure Load Balancer

1. On MIA-CL1, in the Azure portal within the Internet Explorer window, on the Hub menu, click New,
click Networking, and then, in the Networking blade, click Load Balancer.
2. In the Create load balancer blade, specify the following settings:
o Name: ResDevWebLB
o Scheme: Public
o Public IP address: Create a new dynamic address named ResDevWebLBIP.
o Subscription: Your subscription.
o Pin to dashboard: Unchecked

3. Click Create. Wait for the deployment to complete. This should take a few seconds.
4. On the Startboard of the Azure portal, click Browse, select Load Balancers from the list of services,
and then in the Load balancers blade, click ResDevWebLB.
5. In the Setting blade of the ResDevWebLB Load balancer, click Backend pools, and then, in the
Backend address pools blade, click Add.
6. In the Add backend pool blade, in the Name text box, type ResDevWebLBPool, and then click Add
a virtual machine.
7. In the Choose virtual machines blade, click Choose an availability set, and then, in the Choose an
availability set blade, click ResDevWebAS.
8. In the Choose virtual machines blade, click Choose the virtual machines, click the check boxes to
the left of ResDevWebVM1 and ResDevWebVM2, and then click Select.
9. In the Choose virtual machines blade, click OK.
10. In the Add backend pool blade, click OK.
11. In the Setting blade for ResDevWebLB, click Probes, and then in the Probes blade, click Add.
12. In the Add probe blade, specify the following settings, and then click OK:
o Name: ResDevWebProbe80
o Protocol: HTTP
o Port: 80
o Path: /
o Interval: 5
o Unhealthy threshold: 2
13. In the Setting blade for ResDevWebLB, click Load balancing rules, and then in the Load balancing
rules blade, click Add.
14. In the Add load balancing rule blade, complete the following , and then click OK:
o Name: ResDevWebLBRule80
o Protocol: TCP
o Port: 80
o Backend Pool: ResDevWebPool
o Probe: ResDevWebProbe
o Backend port: 80
o Session persistence: None
o Idle timeout: 4
o Floating IP: Disabled
15. Refresh the Azure portal. In the Setting blade of ResDevWebLB, you should be able to identify its
public IP address. Note that at this point, you will not be able to connect to the two virtual machines
in the backend pool, because they are not running a web server and the connectivity is additionally
restricted by default network security group settings. You will change these settings later in this lab.
Results: After completing this exercise, you should have created an availability set for Azure IaaS v2 virtual
machines and configured them up as a load balanced pair.
Exercise 2: Implementing DSC

 Task 1: Install and configure IIS by using DSC and Windows PowerShell
1. On MIA-CL1, start File Explorer and browse to the D:\Labfiles\Lab04\Starter folder.
2. In the D:\Labofiles\Lab04 folder, right-click on the IISInstall.ps1 file and select Edit from the right-
click menu. This will open the file in the Windows PowerShell ISE.
4. Close the Windows PowerShell ISE window.
5. In File Explorer, right click on the D:\Labfiles\Lab04\Starter\DeployAzureDSC.ps1 file and select

Edit from the right-click menu. This will open the file in the Windows PowerShell ISE window.
6. Review the content of the script. Note the variables that it uses, including the storage account and its
key. The script first publishes the DSC configuration defined in the Install.ps1 file to the same storage
Azure Agent VM DSC extension on two virtual machines deployed in the previous lab by referencing
that URL. The script generates a shared access signature token that provides read only access to the
blob representing the DSC configuration archive.
8. On MIA-CL1, open Internet Explorer and navigate to the Azure portal at https://portal.azure.com.
9. Within the Azure portal, click Virtual Machines on the Hub menu.
10. In the Virtual machines blade, click the ResDevWebVM1 entry.
11. In the ResDevWebVM1 blade, click Connect.

12. When prompted whether to open or save the ResDevWebVM1.rdp file, click Open.
13. If prompted to confirm that you want to connect, click Connect.
14. When prompted to enter credentials to connect, type Student as the user name and Pa$$w0rd as
the password.
15. If prompted again to confirm that you want to connect, click Yes.
16. After you establish a Remote Desktop session to the VM, in the Server Manager window, verify that
IIS appears in the left pane, indicating that the Web Server (IIS) server role is installed.
17. Repeat steps 10 through 16 for the other virtual machine ResDevWebVM2.
18. After completing the tasks, switch back to your lab computer MIA-CL1. Leave both Remote Desktop
sessions open.
 Task 2: Test the DSC configuration and virtual machine availability

1. In the Azure portal within the Internet Explorer window on MIA-CL1, on the Hub menu, click
Resource groups.
2. In the Resource groups blade, click ResDevWebAS.
3. In the ResDevWebAS blade, in the Resources tile, click the ResDevWebVM1 entry representing the
network security group (with the icon in the form of a shield). This will open the corresponding blade
along with its Settings blade.
4. In the Settings blade of the ResDevWebVM1 network security group, click Inbound security rules.
5. In the Inbound security rules blade, click Add.

6. In the Add inbound security rue blade, specify the following settings:
o Name: allow-http
o Priority: 1100
o Source: Any
o Protocol: TCP

o Destination: Any
o Action: Allow
7. Click OK.
8. In the breadcrumb trail at the top of the portal interface, click ResDevWebAS to return to the
ResDevWebAS blade.
9. In the ResDevWebAS blade, in the Resources tile, click the ResDevWebVM2 entry representing the
network security group (with the icon in the form of a shield). This will open the corresponding blade
along with its Settings blade.
10. In the Settings blade of ResDevWebVM2 network security group, click Inbound security rules.
11. In the Inbound security rules blade, click Add.
12. In the Add inbound security rules blade, specify the following settings:
o Name: allow-http
o Priority: 1100
o Source: Any
o Protocol: TCP

o Destination: Any
o Action: Allow
13. Click OK.
14. In the breadcrumb trail at the top of the portal interface, click ResDevWebAS to return to the
ResDevWebAS blade.
15. In the ResDevWebAS blade, in the Resources tile, click ResDevWebLB, representing the load
balancer.
16. In the ResDevWebLB blade, note the value of its IP address entry.
17. Open a new InPrivate Browsing Internet Explorer session and type the IP address that you noted in
the previous step in the navigation bar, and then press the Enter key.
18. Verify that you can access the default IIS webpage.
19. Close the InPrivate Browsing window.
20. Switch to the Remote Desktop session on ResDevWebVM1. On the Tools menu in the Server
Manager window, select Services.
21. In the Services window, scroll down to the World Wide Web Publishing Service entry, right click on
it, and select Stop on the context sensitive menu.
22. Switch to the Remote Desktop session on ResDevWebVM2. On the Tools menu in the Server
Manager window, select Services.
23. In the Services window, scroll down to the World Wide Web Publishing Service entry, right-click on
it, and select Stop on the context sensitive menu.
24. Switch back to MIA-CL1. From MIA-CL1, open a new InPrivate Browsing Internet Explorer session. In
the new Internet Explorer window, click the cogwheel icon in the upper-right corner, click Safety on
the drop-down menu, and then click Delete browsing history.
25. In the Delete Browsing History dialog box, click Delete.
26. In the InPrivate Browsing Internet Explorer window, type the IP address of the load balancer in the
navigation bar, and then press the Enter key.
27. Verify that the This page can’t be displayed message appears.
28. Switch back to the Services window in the Remote Desktop session on ResDevWebVM1.
29. In the Services window, right-click the World Wide Web Publishing Service entry, and then select
Start from the right-click menu.
30. Once the service is running, switch back to MIA-CL1 and refresh the InPrivate Browsing Internet
Explorer window. Verify that you can again access the default IIS webpage.
Note: Optionally you can repeat this sequence, but this time stopping the World Wide
Web Publishing Service on ResDevWebVM1 and starting it on ResDevWebVM2. As long as the
service is running on at least one of the two virtual machines, you should be able to access the
webpage.
Results: After completing this exercise, you should have implemented DSC.
Exercise 3: Implementing Storage Space–based volumes

 Task 1: Attach VHDs to an Azure VM
1. On MIA-CL1, in the Azure portal within the Internet Explorer window, on the Hub menu, click Virtual
Machines.
2. In the Virtual machines blade, click ResDevWebVM1. This automatically opens the
ResDevWebVM1 blade and its Settings blade.
3. In the Settings blade of ResDevWebVM1, click Disks.
4. In the Disks blade, click Attach new.
5. In the Attach new disk blade, specify the following settings, and then click OK:
o Name: Accept the default

o Type: Standard
o Size: 1023
o Location: Note that this cannot be changed since the location of the VM determines the
location of its disks.
o Host caching: None
6. Repeat the steps 4 and 5 to attach one more new data disks. Note that with current VM size
(Standard A1), there is a limit of 2 data disks per VM.
 Task 2: Configure a Storage Spaces simple volume

1. On MIA-CL1, switch to the Remote Desktop session to ResDevWebVM1.
2. In the Remote Desktop session, in the Server Manager window, click File and Storage Services.
3. In the Servers navigation pane on the left side, click Storage Pools.
4. In the STORAGE POOLS pane, click the TASKS menu, and then click New Storage Pool on the drop-
down menu. This will open the New Storage Pool Wizard.
5. On the Before you begin page, click Next.
6. On the Specify a storage pool name and subsystem page, type StoragePool1 in the Name text
box, and then click Next.
7. On Select physical disks for the storage pool, select the check boxes next to PhysicalDisk2 and
PhysicalDisk3 (which represent disks you attached in the Azure portal), and then click Next.
8. On the Confirm selections page, click Create.
9. On the View results page, select the Create a virtual disk when this wizard closes check box, and
then click Close. This will launch the New Virtual Disk Wizard.
11. On the Select the storage pool page, ensure that StoragePool1 is selected, and then click Next.
12. On the Specify the virtual disk name page, type VirtualDisk1 in the Name text box, and then click
Next.
13. On the Select the storage layout page, ensure that Simple is selected, and then click Next.
14. On the Specify the provisioning type page, ensure that Fixed is selected, and then click Next.
15. On the Specify the size of the virtual disk page, select Maximum size, and then click Next.
17. On the View results page, ensure that the Create a volume when this wizard closes check box is
selected, and then click Close. This will open the New Volume Wizard.
19. On the Select the server and disk page, ensure that VirtualDisk1 is selected, and then click Next.
20. On the Specify the size of the volume page, accept the default (2.00 TB), and then click Next.
21. On the Assign to a drive letter or folder page, accept the default drive letter (F:), and then click
Next.
22. On the Select file system settings page, accept the default settings (NTFS with default allocation
unit size), and then click Next.
24. On the Completion page, click Close.
25. From the desktop of ResDevWebVM1, open File Explorer, and then verify that there is a new drive F
with 2 TB of available disk space.
26. Close the Remote Desktop session to ResDevWebVM1.


3. Type the following command, and press Enter:
Reset-Azure
Note: This script will remove Azure services in your subscription. We, therefore, recommend
own Azure account.
The script will take 5 to 10 minutes to reset your Microsoft Azure environment, before it is ready
for the next lab. The script removes all storage, VMs, virtual networks, cloud services, and
resource groups.
Results: After completing this exercise, you should have implemented Storage Spaces based volumes.
L5-37
Module 5: Implementing Azure App Service

Lab: Implementing web apps
Exercise 1: Creating web apps
 Task 1: Create a web app
1. Ensure that the MSL-TMG1 and 20533C-MIA-CL1 virtual machines are running, and then sign in to
20533C-MIA-CL1 as Student with the password Pa$$w0rd.
2. Open Internet Explorer, browse to http://portal.azure.com, and then sign in using a Microsoft
account that is either the Service Admin or co-admin of your subscription.
3. In the top-left corner of the portal, click New, and then click Web+Mobile.
4. In the Web+Mobile blade, click Web App.
5. In the Web App blade, in the App name text box, type a unique name. If the name is unique and
valid, a green check mark appears.
6. In the Web App blade, in the Resource Group, verify that New is selected from drop down list, and
then in the New resource group name text box, type AdatumLabWebRG.
7. In the Web App blade, click the App Service plan/Location link.
8. In the App Service plan blade, click Create New.
9. In the App Service plan text box, type WebAppStandardPlan.
10. In the Location drop-down list, select a location near you.

11. In Pricing tier, select S1 Standard, and then click OK.
12. In the Web App blade, click Create. The web app creation process may take several minutes.
 Task 2: Add a deployment slot

1. On the left of the Azure portal, click Browse, and then click App Services.
2. In the App Services blade, click the web app that you created in the first task.
3. In the Settings blade, scroll down to locate the PUBLISHING section, and then click Deployment
slots.
4. In the Deployment slots blade, click Add Slot.
5. In the Add a slot blade, in the Name text box, type Staging.
6. In the Configuration Source list, select the web app you created in the first task, and then click OK.
Azure adds the new deployment slot to the list.
7. Close the Deployment slots blade.
8. Open Windows PowerShell by clicking its shortcut in the taskbar.
9. Sign in to the Azure subscription by typing the following command in the Azure PowerShell window,
and then pressing Enter:
10. Sign in to the Azure subscription with a Microsoft account that is either the Service Admin or co-
admin of your subscription.
L5-38 Implementing Azure App Service
11. If you have multiple subscriptions, to select the target one type the following commands at the each
followed by pressing Enter:
Get-AzureRmSubsctiption
Set-AzureRmContext -SubscriptionName “Name of your subscription”
12. Type the following PowerShell command, and then press Enter:
Get-AzureRMWebApp
13. Verify that the list of web apps includes the web app that you created in Task 1.
14. Type the following Azure PowerShell command, and then press Enter:
Get-AzureRMWebAppSlot –ResourceGroupName AdatumLabWebRG -name “Name of your WebApp”
15. Verify that the web app is listed the staging slot you created in this task.
16. Keep the Azure PowerShell window open.
 Task 3: Configure deployment credentials

1. In the Azure portal, in the web app that you created in Task 1, in the Settings blade, scroll down to
the Publishing section, and then click Deployment credentials.
2. In the Set Deployment credentials blade, in the FTP/Deployment user name text box, type
ftpadminXXXX (replace XXXX is a unique number).
3. In the Password text box, type Pa$$w0rd.
4. In the Confirm password box, type Pa$$w0rd, and then click Save.
5. Close the Set deployment credentials blade.
Results: After completing this exercise, you should have created a new web app in the Azure portal, and
configured the new web app with deployment slots and credentials.
Exercise 2: Deploying a web app

 Task 1: Obtain a publishing profile
1. In the Azure portal, in the blade that shows the web app that you created in the Exercise 1, in the
command bar located on the top of the blade, click Get publish profile.
2. In the dialog box, click Save. Internet Explorer saves the publishing profile in the Downloads folder.
3. On the taskbar, click Visual Studio 2015.
4. On the File menu, click Open, and then click Project/Solution.
5. Browse to the folder D:\LabFiles\Lab05\Starter\AdatumWebsite, click AdatumWebsite.sln, and

then click Open.
6. On the Debug menu, click Start Debugging.
7. Under A. Datum Corporation, click Learn More.
8. Click Contact.

 Task 2: Deploy a web app

1. In Visual Studio, on the Debug menu, click Stop Debugging.
2. In the Solution Explorer, right-click the AdatumWebsite project, and then click Publish.
3. In the Publish Web Wizard, on the Profile page, click Import.
4. In the Import Publish Settings dialog box, click Browse.
5. Browse to the Downloads folder.
6. Select the .PublishSettings file that you downloaded in Task 1 of this exercise, and then click Open.
7. In the Import Publish Settings dialog box, click OK.
8. On the Connection page, click Validate Connection.

Visual Studio connects to the Azure web app. If the connection is valid, a green tick mark appears.
9. Click Next.
10. On the Settings page, in the Configuration drop-down list, select Release.
11. Click Next.
12. On the Preview page, click Start Preview.
13. Examine the list of changes to apply to the web app.

14. Click Publish.
Note: The publish operation may take approximately two to three minutes. When the
operation is complete, Microsoft Edge opens and displays the new web app hosted in
Azure.
15. Verify that A. Datum’s web app is open in Microsoft Edge, and then verify the web app’s current
address.
Results: After completing this exercise, you should have a deployed a web app hosted in Azure that you
can open with any common web browser.
Exercise 3: Managing web apps

 Task 1: Deploy a web app for staging
1. In Internet Explorer, in the Azure portal, navigate to the web app you created in Exercise 1, Task 1.
2. In the Settings blade, scroll down to the PUBLISHING section, and then click Deployment Slots.
3. In the Deployment slots blade, click the staging slot yourwebapp-staging that was created in
Exercise 1, Task 2.
4. In the yourwebapp(Staging) blade from the command bar located on the top section of the blade,
click Get publish profile.
5. In the dialog box, click Save.

7. On the File menu, click Open, and then click Project/Solution.
8. Browse to the folder D:\LabFiles\Lab05\Starter\NewAdatumWebsite.
9. Click AdatumWebsite.sln, and then click Open.
10. In Solution Explorer, right-click the AdatumWebsite project, and then click Publish.
11. In the Publish Web Wizard, on the Profile page, click Import.
13. In the Downloads folder, select the YourWebapp(Staging).PublishSettings file, and then click
Open.

16. If the connection details are correct, a green tick mark appears.
17. Click Next.
18. In the Configuration drop-down list, ensure that Release is selected, and then click Next.
20. Examine the files that are to be published, and then click Publish.
21. When the publish operation is complete, Microsoft Edge opens and displays the new web app in the
staging slot.
22. Close Microsoft Edge and Visual Studio.
 Task 2: Swap deployment slots

1. In the Azure portal, click Browse, and then click App Services.
2. In In the App Services blade, click the web app you created in Exercise 1, Task 1.
3. In the yourwebapp blade, under the Essentials section, click the URL link for your web app. Notice
the color scheme has not changed.
4. Close the tab that displays the A. Datum web app.
5. In the Azure portal, in the Settings blade, scroll down to the PUBLISHING section, and then click
Deployment slots.
6. In the Deployment slots blade, on the command bar, click Swap.
7. In the Swap blade, in the Swap type drop-down list, verify that Swap is selected.
8. In the Source drop-down list, ensure that Staging is selected.
9. In the Destination drop-down list, ensure that production is selected, and then click OK.
10. Wait until swap operation completes.
11. Close all the open blades except yourwebapp blade.

12. In the yourwebapp blade in Essentials section, click the URL link for your web app.
Notice that the color scheme is new.
13. Close the tab that displays the A. Datum’s web app.
 Task 3: Roll back a deployment

1. In the Azure portal, in the yourwebapp blade in the command bar at the top, click Swap.
2. In the Swap blade, in the Swap type drop-down list, verify that Swap is selected.
3. In the Source drop-down list, select Staging.
4. In the Destination drop-down list, select production, and then click OK button.
5. Wait until the Swap operation completes.
6. In the yourwebapp blade, in Essentials section, click the URL link for your web app.
7. Notice that the color scheme is reverted to the old scheme.
8. Close the A. Datum tab in Internet Explorer.
Results: After completing this exercise, you should have an updated web app staged and published in
Azure.
Exercise 4: Implementing Traffic Manager

 Task 1: Deploy a web app to another region
1. Switch to Microsoft Azure PowerShell.
Get-AzureRMWebApp
Note the name of your original web app and location.
3. Choose an Azure region that is different from the location of the original web app. This will become
the “SecondLocation”.
4. At the command prompt, type the following command to create a new resource group, and then
press Enter:
New-AzureRMResourceGroup –Name AdatumLabWebRG2 –Location “SecondLocation”
5. At the command prompt, type the following command to create new App Service Plan, and then
press Enter:
New-AzureRMAppServicePlan –Location “SecondLocation” –Tier Standard –Name StandardPlan

–ResourceGroupName AdatumLabWebRG2
6. At the command prompt, type the following command to create a new web app, and then press
Enter:
New-AzureRMWebApp –ResourceGroupName AdatumLabWebRG2 –Name “WebAppName2” –Location

“SecondLocation” –AppServicePlan StandardPLan
WebAppName2 is the name of your first web app with the number 2 appended, and SecondLocation
is the location you chose in step 4.
7. Switch to the Azure portal in the Internet Explorer window.
8. On the left side of the Azure portal, click Browse, and then click App Services.
9. In the App Services blade, click WebAppName2.
10. In the WebAppName2 blade, on the command bar located at the top of the blade, click Get publish
profile.
11. When prompted, click Save.

13. In the Visual Studio, on the File menu, click Open, and then click Project/Solution.
14. Browse to the folder D:\LabFiles\Lab05\Starter\AdatumWebsite.
15. Click AdatumWebsite.sln, and then click Open.
16. In Solution Explorer, right-click the AdatumWebsite project, and then click Publish.
17. In the Publish Web Wizard, on the left, click Profile, and then click Import.

19. In the Downloads folder, select the WebAppName2.PublishSettings file, and then click Open.

22. If the connection details are correct, a green tick mark appears.
23. Click Next.
24. In the Configuration drop-down list, ensure that Release is selected, and then click Next.
26. Examine the files that will be published, and then click Publish.
27. When the publish operation completes, Internet Explorer opens and displays the new web app.
 Task 2: Create a Traffic Manager profile

1. In Internet Explorer, in the Azure portal, click New, and then click Networking.
2. In the Networking blade, click Traffic Manager profile.
3. In the Create Traffic Manager profile blade, in the Name text box, type a unique name. This will be
appended with the suffix trafficmanager.net. If the name is unique and valid, a green checkmark
appears.
4. In the Routing Method drop-down list, select Performance.
5. In the Resource Group drop down list, ensure that New is selected.
6. In the New resource group name text box, type AdatumLabTMRG.
7. In the Resource group location drop-down list box, select the Azure region that is closest to your
location, and then click Create. Wait until the Traffic Manager profile is created.
 Task 3: Add endpoints, and configure Traffic Manager

1. In the hub menu on the left side, click Browse, and then select Traffic Manager Profiles.
2. In the Traffic Manager profiles blade, locate and click your previously created profile.
3. In the Settings blade, click Endpoints.

4. In the Endpoints blade, click Add.
5. In the Add endpoint blade, in the Type drop-down list, select Azure endpoint.
6. In the Name text box, type the name of your web app, which you created in Exercise 1.
7. In the Target resource type drop-down list of websites, select App Service.
8. Click Choose an app service.
9. In the Resource blade, select the web app that you created in Exercise 1.
10. Click OK to add the endpoint.
11. Repeat steps 4 through 10 to add a second endpoint for the web app that you created in Exercise 4.
12. Close the Endpoints blade.
13. In the Settings blade, click the Configuration link.
14. In the Configuration blade, in the DNS time to live (TTL) text box, remove the original setting, and
then type 30.
15. On the command bar at the top, click Save.
16. Close the Configuration blade, and then close the Settings blade.
 Task 4: Test Traffic Manager

1. In Internet Explorer, in the Azure portal, in the Yourname Traffic Manager blade, click the link under
the DNS name section.
2. Internet Explorer displays the Adatum web app.

3. On the Start menu, type cmd, and then press Enter.
nslookup dnsname
where dnsname is the DNS name of the traffic manager profile that you accessed in step 1.
5. Note the aliases that are returned.
6. In Internet Explorer, switch to the tab that displays the Azure portal.
7. In the Yourname Traffic Manager blade, click the All settings link.
8. In the Settings blade, click the Endpoints link.
9. In the Endpoints blade, in the list of endpoints, select the web app that you created in Exercise 1.
10. In the YourWebApp blade, click Edit. Under Status, click Disabled, and then click Save.
11. Switch to the command prompt, type the following command, and then press Enter:
nslookup dnsname
Please note dnsname is the DNS name that you used in step 4.
12. Note that the aliases that return are different from those returned in step 4.
Note: If the aliases are not changed, at the command prompt, reissue the nslookup
commands until there is a change.
 Task 5: Reset the Azure environment

Reset-Azure
subscription.
The script will take approximately two or three minutes to reset your Azure environment, so that
you are ready for the next lab. The script removes all storage, virtual machines, virtual networks,
cloud services, and resource groups.
Important: The script may not have exclusive access to a storage account so that it can delete it.
If this occurs, you will see an error. If you find objects remaining after the reset script is complete,
you can rerun the Reset-Azure script, or use the Azure portal to delete all objects in your Azure
subscription manually, with the exception of the default directory. Do not delete it.
Results: After completing this exercise, you should have a web app set up in two Azure regions and Traffic
Manager configured to distribute requests between them.
L6-45
Module 6: Planning and implementing storage, backup, and

recovery services
Lab: Planning and implementing Azure
Storage
Exercise 1: Creating and configuring Azure Storage
 Task 1: Create a storage account
1. Ensure that you are signed in to MIA-CL1 as Student with the password Pa$$w0rd and that the
setup script that you ran in the previous demonstration to prepare the environment has completed.
2. Start Internet Explorer, and then browse to https://portal.azure.com. When prompted, sign in by
using the Microsoft account that is the Service Administrator or Co-Administrator of your Microsoft
Azure subscription.
3. On the Hub menu, click New, and then click Data + Storage.
4. In the Data + Storage blade, click Storage account.

5. In the Create storage account blade, apply the following settings, and then click Create:


o Resource group: Make sure that +New appears in the drop-down list and then type Asset-
Management in the New resource group name text box

6. At the top of the portal window menu, click the Notifications icon, and then wait for the notification
that the storage account has been created.
7. On the Hub menu, click Browse, and then click Storage accounts (classic).
8. In the Storage accounts (classic) blade, click the storage account that you just created.
9. In the blade for your storage account, click the Blobs tile.
10. In the Blob service blade, click Container in the toolbar.
11. In the New container blade, apply the following settings, and then click Create:
o Name: asset-images
o Access type: Private
12. Close the Blob service blade.
13. On the taskbar, right-click Windows PowerShell, and then click Run ISE as Administrator. Click Yes
when prompted.
14. In the Windows PowerShell Interactive Scripting Environment (ISE), click File, and then click Open.
L6-46 Planning and implementing storage, backup, and recovery services
15. In the Open dialog box, browse to D:\Labfiles\Lab06\Starter\, click ExampleCommands.ps1, and
then click Open.
16. If the Script pane is not visible, on the View menu, click Show Script Pane.
17. In Windows PowerShell ISE, in the Script pane, type the name of the storage account that you
created in the previous task.
18. Leave the Internet Explorer window open. You will use it later in this lab.
 Task 2: Install AzCopy

1. In Internet Explorer, open a new tab, and then browse to http://aka.ms/AzCopy.
2. In the Download and install AzCopy section, click the link to Download the latest version of
AzCopy.
3. When prompted to run or save the file, click Run. Then click Yes if prompted to allow the program to
make changes to the computer, and then complete the wizard to install AzCopy by using the default
installation options.
4. Right-click Start, click System, and then in the System window, click Advanced system settings.
5. In the System Properties dialog box, on the Advanced tab, click Environment Variables.
6. In the Environment Variables dialog box, in the System variables list, select Path, and then click
Edit.
7. In the Edit environment variable dialog box, click New.

8. In the text box, type C:\Program Files (x86)\Microsoft SDKs\Azure\AzCopy, and then click OK.
9. In the Environment Variables dialog box, click OK.
10. In the System Properties dialog box, click OK, and then close the System window.
11. Right-click Start, click Command Prompt (Admin), and then click Yes when prompted.
AzCopy /?
13. View the syntax information that displays. Leave the Command Prompt window open for the next
task.
 Task 3: Use AzCopy to upload blobs

1. In Internet Explorer, on the Microsoft Azure tab, in the blade for your storage account, click the
Keys icon.
2. On the Manage keys blade, click the Copy icon next to the primary access key. If prompted to allow
access to the Clipboard, click Allow access.
3. In the Command Prompt window, enter the following commands to change the current directory
context:
D:
4. Switch to Windows PowerShell ISE.

5. In Windows PowerShell ISE, in the Script pane, locate the following code:
AzCopy /Dest:https://<your storage account>.blob.core.windows.net/asset-images

/destkey:<your primary access key> /Source:asset-images
6. Replace <your storage account> with your storage account name.
7. Replace <your primary access key> with your primary access key.
8. In Windows PowerShell ISE, in the Script pane, select the code that you just edited. Click Edit, and
then click Copy.
9. Switch to the Command Prompt window.
10. In the Command Prompt window, click the control box at the top left of the window, point to Edit,
click Paste, and then press Enter to run the command.
11. Wait for the command to complete, and then view the file transfer information that displays.
12. Close the Command prompt window.
Results: At the end of this exercise, you should have created a new Azure storage account with a
container named “asset-images.”
Exercise 2: Using Azure File storage

 Task 1: Create a file share and upload files
1. Switch to Windows PowerShell ISE.
2. Click File, and then click Open.

3. In the Open dialog box, browse to D:\Labfiles\Lab06\Starter\, click FileShare.ps1, and then click
Open.
4. In Windows PowerShell ISE, in the command prompt pane, enter the Get-AzureAccount command,
and then verify that your Microsoft account displays.
Note: If your account does not display, enter the Add-AzureAccount command, and then
sign in by using your Microsoft account.
5. In the Script pane, in the $storageAccountName variable declaration at the beginning, replace the
<your_storage_account_name> value with the name of the Azure storage account that you created in
the previous task.
6. Review the script, noting that it:
o Declares variables named $shareName and $folderName for the file share and the folder to
create.
o Uses the New-AzureStorageShare cmdlet to create a share.
o Uses the New-AzureStorageDirectory cmdlet to create a folder in the share.

o Finds the folder where the script is stored, and then declares a variable named $sourceFolder that
references the invoices subfolder.
o Iterates through the files in the source folder, and then uses the Set-AzureStorageFileContent
cmdlet to write each file to the folder in the file share.
7. Save the script, and then on the toolbar, click Run Script.
8. Observe the script as it runs, and then view the output. When you finish, close Windows PowerShell
ISE without saving any changes.
 Task 2: Access a file share from a VM

1. In Internet Explorer, on the Azure portal, click Browse, click Virtual machines (classic), and then in
the Virtual machines (classic) blade, click AdatumSvr1.
2. In the AdatumSvr1 blade, click Connect, and then when prompted to open or save the
AdatumSvr1.rdp file, click Open.
3. When prompted to connect, click Connect, enter the following credentials, and then click OK:
o User name: AdatumSvr1\Student
4. If prompted to connect again, click Yes, and then wait for the remote desktop session to open and
initialize. If you are promoted to find PCs, devices, and content on this network, click No.
5. When Server Manager starts, on the Local Server page, click the status for IE Enhanced Security
Configuration, select Off for Administrators, and then click OK.
6. Close Server Manager.
7. In the AdatumSvr1 remote desktop window, switch to the Start page, and then click Internet
Explorer. If prompted to set up Internet Explorer, select Use recommended security, privacy, and
compatibility settings, and then click OK.
8. Browse to https://portal.azure.com, and then sign in by using the Microsoft account that is the
Service Administrator or Co-Administrator of your Azure subscription.
9. On the Hub menu, click Browse, and then click Storage accounts (classic).
10. In the Storage accounts (classic) blade, click the storage account that you created in the previous
exercise, and then in the blade for your storage account, click the Keys icon.
11. On the Manage Keys blade, click the Copy icon next to the primary access key. If prompted to allow
access to the Clipboard, click Allow access.
12. Right-click Start, and then click Command Prompt (Admin).
13. In the Command Prompt window, enter the following command to map a network drive to the assets
file share in your Azure storage account. Replace both instances of storage_account with the name of
your storage account, and then press Enter:
net use z: \\storage_account.file.core.windows.net\assets /u:storage_account
14. When prompted, paste the access_key from the Clipboard (to paste into a Command Prompt window,
click the control box at the top left of the window, point to Edit, and then click Paste).
15. At the command prompt, enter the following command to view the contents of the invoices folder in
drive Z, which is now mapped to the assets file share that you created in a previous task:
dir z:\invoices
16. Verify that three invoice files are listed.
17. Close the Command Prompt window and Internet Explorer, and then sign out of the remote desktop
session to AdatumSvr1.
Results: At the end of this exercise, you should have created a file share named “assets” that contains a
folder named “invoices.” This folder will contain three invoice documents and will be accessible on the
AdatumSvr1 virtual machine (VM).
Exercise 3: Protecting data with Azure Backup

 Task 1: Create a backup vault
1. On the MIA-CL1, open Internet Explorer, and then browse to https://manage.windowsazure.com.
2. If prompted, sign in by using the Microsoft account that is the Service Administrator or
3. In the Azure classic portal, click NEW, click DATA SERVICES, click RECOVERY SERVICES, click
BACKUP VAULT, and then click QUICK CREATE.
4. Enter a valid, unique name, select your closest region, and then click CREATE VAULT.
 Task 2: Obtain vault credentials

1. On the Azure classic portal, click RECOVERY SERVICES on the Hub menu, and then click your new
backup vault.
2. On the backup vault Quick Start page, click Download vault credentials.
3. Click Save to download the vault credentials to the Downloads folder.
4. After the credentials download, you will be prompted to open the folder. Click the prompt window.
 Task 3: Install and configure the Azure Backup agent

1. On the Azure classic portal, on the Quick Start page of your backup vault, under Download Azure
Backup Agent, click the Agent for Windows Server or System Center Data Protection Manager
or Windows Client link.
2. When prompted to run or save the file, click Run. When prompted to allow the program to make
changes, click Yes, and then complete the wizard to install the agent. Use the default installation
options, and if prompted, choose the option to use Microsoft Update to check for updates.
3. When installation is complete, click Close.

4. Minimize all active windows, and then on the desktop, double-click Microsoft Azure Backup. When
prompted to allow the program to make changes, click Yes.
5. In the Microsoft Azure Backup window, in the Actions pane, click Register Server.
6. In the Register Server Wizard, on the Proxy Configuration page, click Next.
7. On the Vault Identification page, click Browse, navigate to the Downloads folder, select the
credentials that you created earlier, and then click Open.
8. On the Vault Identification page, click Next.
9. On the Encryption Setting page, click Generate Passphrase, click Browse, browse to the
D:\Labfiles\Lab06\Starter folder, and then click OK.
10. Click Register, and then when registration is complete, click Close.
11. Leave Azure Backup open for the next task.
 Task 4: Create a backup schedule

1. In Azure Backup, in the Actions pane, click Schedule Backup.
2. In the Schedule Backup Wizard, on the Getting started page, click Next.
3. On the Select Items to Backup page, click Add Items.

4. In the Select Items dialog box, expand D, expand Labfiles, expand Lab06, expand Starter, select the
following folders, and then click OK:
o asset-images
o invoices
5. On the Select Items to Backup page, click Next.
6. On the Specify Backup Schedule page, in the first drop-down list box below the At following times
(Maximum allowed is three times a day) box, select 4:30 AM, and then click Next.
7. On the Select Retention Policy page, accept the defaults, and then click Next.
8. On the Choose Initial Backup type page, accept the defaults, and then click Next.
9. On the Confirmation page, click Finish. When the backup schedule is created, click Close.
 Task 5: Run a backup

1. In Azure Backup, in the Actions pane, click Back Up Now.
2. In the Back Up Now Wizard, on the Confirmation page, click Back Up.
3. When the backup is complete, click Close, and then close Azure Backup.
4. In Internet Explorer, on the Azure portal, on the page for your backup vault, click REGISTERED
ITEMS.
5. In the TYPE drop-down list box, select Windows server, click the check mark on the right side, and
then verify that the MIA-CL1 server lists as registered.
6. Click PROTECTED ITEMS.

7. In the TYPE drop-down list box, select Files and Folders, click the check mark on the right side, and
then verify that drive D of MIA-CL1 lists as protected.

Reset-Azure
subscription.
6. When prompted for confirmation, press Y and press Enter.

groups.
directory.
Results: At the end of this exercise, you should have created an Azure Backup vault in your subscription,
created Azure Backup vault credentials, and installed the Azure Backup agent on the MIA-CL1 lab
computer. You should have backed up the contents of the asset-images and invoices folders to the
backup vault.
L7-53
Module 7: Planning and implementing Azure SQL Database

Lab: Planning and implementing Azure SQL
Database
Exercise 1: Creating, securing, and monitoring an Azure SQL Database
 Task 1: Create an Azure SQL Database
1. Sign in to the MIA-CL1 lab virtual machine as Student with the password Pa$$w0rd.
2. Start Internet Explorer, browse to https://portal.azure.com, and sign in by using the Microsoft
account that is the Subscription Administrator or Co-Administrator of your Azure subscription.
3. In the Hub menu on the left, click New, click Data + Storage, and then click SQL Database.
4. On the SQL database blade, in the Database name box, type operations.
5. Click Server, and then on the Server blade, click Create a new server.
6. On the New server blade, enter the following settings and then click Select:
o Server name: any valid unique name
o Server admin login: Student

o Location: the closest Azure region (to your location)
o Create V12 server (Latest update): Yes
o Allow azure services to access server: Enabled

7. Ensure that Blank database is selected as the Select source.
8. Click Pricing tier.
9. On the Choose your pricing tier blade, select S1 Standard and click Select.
10. On the SQL database blade, in the Resource group drop-down list, select +New and then in the
New resource group name text box, type OpsRG.
11. On the SQL database blade, ensure that Pin to dashboard is selected and click Create. Then wait for
the SQL Database to be created.
12. After the database is created, the portal will automatically display its Settings blade.
 Task 2: Configure server firewall rules

1. Navigate to the operations blade in the Azure portal in the Internet Explorer window.
2. On the operations blade, click the hyperlink containing the server name.
3. Navigate to the Settings blade of the server and click Show firewall settings.
4. On the Firewall settings blade, note the value of the Client IP address entry.
L7-54 Planning and implementing Azure SQL Database
5. On the Firewall settings blade, specify the following:
where XXX.XXX represents the first two octets of the value of the Client IP address entry.
6. Click Save.
 Task 3: Use SQL Server Management Studio

1. Start SQL Server 2014 Management Studio, and in the Connect to Server dialog box, specify the
following settings (replacing server_name with the unique name you specified when creating your
SQL Database server), and click Connect:
o Login: Student
2. In SQL Server Management Studio, in the Object Explorer, under the server name expand Databases,
and verify that the operations database is listed.
3. In SQL Server Management Studio, navigate to the D:\Labfiles\Lab07\Starter folder, open the
Operations.sql file and view the Transact-SQL code it contains.
4. On the toolbar, in the Available Databases list, select operations. Click Execute.
5. Click New Query and enter the following Transact-SQL code in the new query pane:
SELECT * FROM dbo.serverlist;
6. On the toolbar, in the Available Databases list, ensure that operations is selected. Then click
Execute.
8. Keep SQL Server Management Studio and Internet Explorer open.
 Task 4: View database metrics

1. In Internet Explorer, in the Azure portal, navigate to the operations SQL Database blade.
2. On the operations blade, note the charts displayed in the Monitoring section, which show resource
3. Click Edit, in the Resource utilization chart, click Total database size, and then click OK.
4. Click the chart. This will display the Metric blade.
5. On the Metric blade, click Add alert. Then, on the Add an alert rule blade, specify the following
settings and click OK:
o Name: operations storage alert
o Description: storage alert for operations database

o Threshold: 1024
6. Keep Internet Explorer open for the next exercise.
Results: After completing this exercise, you should have created an Azure SQL Database named
operations on a new server with a name of your choosing. You should also have used SQL Server
Management Studio to create a table named dbo.serverlist and created an alert to help you monitor
database storage.
Exercise 2: Migrating a Microsoft SQL Server Database to Azure SQL

Database
 Task 1: Deploy a database to Azure
1. In SQL Server Management Studio, in Object Explorer, in the Connect drop-down list, click Database
Engine.
2. In the Connect to Server dialog box, specify the following settings, and click Connect:

o Server name: MIA-CL1
o Authentication: Windows Authentication
3. In SQL Server Management Studio, in Object Explorer, under the MIA-CL1 server, expand Databases
and verify that the sales database is listed.
4. Right-click the sales database, point to Tasks, and then click Deploy Database to Windows Azure
SQL Database.
5. In the Deploy Database “sales” Wizard, on the Introduction page, click Next.
6. On the Deployment Settings page, click Connect. Then in the Connect to Server dialog box,
specify the following settings (replacing server_name with the unique name of your SQL Database
server) and click Connect:
o Login: Student
7. On the Deployment Settings page, ensure that the new database name is sales and note the
temporary file name used for the .bacpac file that will be exported and imported, ensure that the
Service Objective is set to S2, and then click Next.
8. On the Summary page, click Finish.
9. On the Results page, verify that the operation completed successfully, and click Close.
10. In SQL Server Management Studio, in Object Explorer, if necessary, right-click the Databases folder
under your Azure SQL Database server and click Refresh to verify that the sales database has been
copied to this server.
 Task 2: Configure SQL Database security

1. In SQL Server Management Studio, in Object Explorer, under your Azure SQL Database server, expand
Security, expand Logins, and verify that only the Student login is listed.
2. Right-click Logins and click New Login. Then, replace the auto-generated Transact-SQL script that is
generated as shown here and then click Execute:
CREATE LOGIN SalesApp

WITH PASSWORD = 'Pa$$w0rd'
GO
3. In Object Explorer, right-click the Logins folder and click Refresh to verify that the SalesApp login
has been created.
4. In Object Explorer, in the Databases folder for your Azure SQL Database server, expand the sales
database, expand Security, and expand Users.
5. Right-click Users and click New User. Then, modify the Transact-SQL script that is generated as
shown below and then click Execute:
CREATE USER SalesApp

FOR LOGIN SalesApp
WITH DEFAULT_SCHEMA = dbo
GO
EXEC sp_addrolemember 'db_owner', 'SalesApp'
GO
6. In Object Explorer, right-click the Users folder and click Refresh to verify that the SalesApp user has
been created.
7. Keep SQL Server Management Studio open for the next exercise.
 Task 3: Configure an application connection string

1. Start Visual Studio, navigate to the D:\Labfiles\Lab07\Starter folder and open the SalesApp.sln
solution.
2. In Solution Explorer, double-click Web.config.
3. In Web.config, note that the SalesConnectionString element contains a connectionString attribute

that connects to the sales database on the localhost server using integrated security (Windows
authentication).
4. In Internet Explorer, on the tab containing the preview Azure portal, on the Hub menu, click Browse
and then click SQL databases.
5. On the SQL databases blade, click the sales database.
6. On the sales blade, click Show database connection strings.

7. On the Database connection strings blade, click the Click to copy icon for the ADO.NET
connection string. If prompted, click Allow access.
8. Minimize Internet Explorer, you will return to it in the next exercise.
9. In Visual Studio, in Web.config, select the existing value for the connectionString attribute and then
paste the connection string you copied to replace it.
10. In the pasted connection string, set the value of the User ID parameter to SalesApp@server_name
(where server_name is the unique name of your Azure SQL Database server). Next, set the value of
the Password parameter to Pa$$w0rd (by replacing the {your_password_here} placeholder. The
new connectionString value should look similar to this (on a single line):
1433;Database=sales; User ID=SalesApp@server_name;
11. Save Web.config. Then on the Debug menu, click Start Debugging.
12. When Internet Explorer opens, verify that the sales application shows invoice history data for the
selected customer. The data is retrieved from the sales database you migrated to Microsoft Azure SQL
Database.
13. Close the Internet Explorer window that contains the Customer Invoice History page, ensure that
Visual Studio debugger is stopped, and then close Visual Studio, saving changes if prompted.
Results: After completing this exercise, you should have deployed the sales SQL Server database on the
local SQL Server instance to your Azure SQL Database server, and configured the SalesApp web
application to use a connection string for the new Azure SQL Database.
Exercise 3: Restoring a database

 Task 1: Delete a database
1. In Internet Explorer, in the Azure Portal, in the Hub menu, click Browse, and then click SQL
Database.
2. On the SQL Databases blade, click the operations database.
3. On the operations blade, click Restore.
4. On the Restore blade, verify whether a restore point is available. If not, wait until that is the case.
5. On the operations blade, click Delete.
6. When prompted to confirm, click Yes.
7. In SQL Server Management Studio, in Object Explorer, under your Azure SQL Database server, right-
click the Databases folder and click Refresh to verify that the operations database is no longer on
the server.
 Task 2: Restore a deleted database

1. In the Hub menu of the Azure Portal, click Browse, select SQL Servers, and click the name of the SQL
server where the operations database was created.
2. On the SQL server blade, scroll down to the Operations section and click Deleted databases.
3. On the Deleted databases blade, click operations.
4. On the Restore blade, set the database name to operations. Notice that you are restoring the most
recent restore point to the same server.
5. Click OK.
Note: If the initial restore attempt fails, try again.
7. In SQL Server Management Studio, in Object Explorer, under your Azure SQL Database server, right-
click the Databases folder and click Refresh to verify that the operations database has been restored.
8. In SQL Server Management Studio, click New Query and enter the following Transact-SQL code in
the new query pane:
SELECT * FROM dbo.serverlist
9. On the toolbar, in the Available Databases list, ensure that operations is selected and then click
Execute.

Reset-Azure

lab.
The script removes all storage, VMs, virtual networks, cloud services, and resource groups
Important: The script might not be able to get exclusive access to a storage account to delete it (if this
occurs, you will see an error). If you find objects remaining after the reset script is complete, you can re-
run the Reset-Azure script, or use the Azure portal and Azure classic portal to manually delete all the
objects in your Azure subscription—with the exception of the default directory.
Results: After completing this exercise, you should have deleted and restored the operations database.
 Task: To prepare for the next module

Leave the virtual machines running for the next module.
L8-61
Module 8: Implementing PaaS cloud services

Lab: Implementing PaaS cloud services
Exercise 1: Deploying a PaaS cloud service
 Task 1: Create a linked resource for a PaaS cloud service
1. Ensure that the MIA-CL1 lab virtual machine is running, and then sign in as Student with the
password Pa$$w0rd.
2. Start Windows PowerShell as an Administrator.
Add-AzureAccount
4. Sign in with the user credentials associated with your Azure account.
Get-AzureLocation | Select-Object Name
6. From the list of Azure regions, identify the one closest to your location, and then note the region’s
name.
New-AzureSqlDatabaseServer –AdministratorLogin ‘yourname’ –

AdministratorLoginPassword ‘Pa$$w0rd’ –Location ‘Your Region’
Replace yourname with your first name and Your Region with the Azure region you noted in step 6.
Get-AzureSqlDatabaseServer
9. Note the server name of the Azure SQL Database server you created in step 7.
10. Launch Windows Internet Explorer, navigate to https://portal.azure.com, and then sign in with the
service administrator account of your Azure subscription.
11. In the left navigation bar, click Browse, and then in the blade that is being displayed, click
SQL databases.
12. In the SQL Database blade, click Add.
13. In the Database name box, type CloudServiceProdDB.
14. Ensure that the name of the server you created in step 7 appears in the Server entry.
15. In the SQL Database blade, click Create.
L8-62 Implementing PaaS cloud services
16. Switch to Windows PowerShell, type the following command, and then press Enter:
New-AzureStorageAccount –StorageAccountName ‘cloudappprodxxx’ –Location ‘Your Region’
Replace xxx with a unique sequence of characters (digits or lowercase letters), and replace Your region
with the Azure region you noted in step 6. If the cmdlet fails because the storage account name you
chose is already in use, try a different one.
To test if the storage account name is already in use, type the following command, and then pressing
Enter:
Test-AzureName –Storage ‘cloudappprodxxx’
Replace xxx with a unique sequence of characters (digits or lowercase letters). An output of False
indicates that the name has not been assigned yet and is available for you to use.
 Task 2: Configure the service definition file

1. On the Taskbar, click Visual Studio 2015.
2. Click File, click Open, and then click File.
3. Browse to D:\LabFiles\Lab08\Starter\ Production\Package.

4. Click ServiceConfiguration.Cloud.cscfg, and then click Open.
5. Locate the <Role> element with the name set to AdatumAdsWebRole.
6. Within that <Role> element, locate the <Instances> element.
7. In the <Instances> element, set the count attribute to 2.
8. Locate the <Role> element with the name set to AdatumAdsWorkerRole.
9. Within that <Role> element, locate the <Instances> element.

10. In the <Instances> element, set the count attribute to 2.
11. Launch Internet Explorer, navigate to https://manage.windowsazure.com, and then if prompted,

sign in with the service administrator account of your Azure subscription.
12. In the Azure classic portal, in the navigation bar on the left, click STORAGE.
13. On the storage page, in the list of storage accounts, click cloudappprodxxx.
14. In the command bar at the bottom, click MANAGE ACCESS KEYS.
15. To the right of the PRIMARY ACCESS KEY box, click Copy, and then click Allow access.
16. In the Manage Access Keys window, click OK.
17. Click the large left arrow at the upper-left side of the window.
18. Switch to Microsoft Visual Studio.
19. In the ServiceConfigurationCloud.cscfg file, locate the <Role> element with the name
AdatumAdsWebRole.
20. Within that <Role> element, locate the <Setting> element with the name set to
StorageConnectionString.
21. Delete the string in the value attribute, leaving the leading and trailing quotation marks, and then
type the following text in its place (on a single line):
AccountName=cloudappprodxxx;AccountKey=
In the preceding text, cloudappprodxxx is the name of the storage account you created in the
previous task.
22. Place the cursor at the end of the text you just typed, and then press Ctrl+V to paste the storage
account primary key.
23. Locate the <Role> element with the name AdatumAdsWorkerRole.
24. Within that <Role> element, locate the <Setting> element with the name
StorageConnectionString.
previous task.
27. Locate the <Role> element with the name AdatumAdsWebRole.
Microsoft.WindowsAzure. Plugins.Diagnostics.ConnectionString.
type the following text in its place (on a single line).
previous task.
Microsoft.WindowsAzure. Plugins.Diagnostics.ConnectionString.
AccountName=cloudappprodXXX;AccountKey=
previous task
35. Switch to the Internet Explorer window displaying the Azure portal.
36. In the CloudServiceProdDB blade, click Show database connection strings.
37. In the Database connection strings blade, click Copy next to the ADO.NET box, and then when
prompted, click Allow access.
38. Switch back to Visual Studio.

AdatumAdsDbConnectionString.
41. Delete the string in the value attribute, leaving the leading and trailing quotation marks.
42. Press Ctrl+V to paste the connection string you copied to the Clipboard.
43. In the connection string you just pasted, locate the text {your_password_here}.
44. Delete the located text, and then replace it with Pa$$w0rd.
45. Click File, and then click Save ServiceConfiguration.Cloud.cscfg.
 Task 3: Deploy the PaaS cloud service

1. In the Internet Explorer window displaying the Azure classic portal, in the left navigation bar, click
CLOUD SERVICES.
2. On the toolbar at the bottom, click NEW, and then click CUSTOM CREATE.
3. In the URL box, type your name followed by today’s date in the MMDDYY format. If a green check
mark does not appear, try another name.
4. In the REGION OR AFFINITY GROUP drop-down list, select the same Azure region you used in
task 1.
5. Select the Deploy a cloud service package check box, and then click Next.
6. In the DEPLOYMENT NAME box, type AdatumAdsProd.
7. Next to the PACKAGE box, click FROM LOCAL.
8. Browse to D:\LabFiles\Lab08\Starter\Production\Package.
9. Click AdatumAds.cspkg, and then click Open.
10. Next to the CONFIGURATION box, click FROM LOCAL.

12. Click Complete.
Note: The deployment process for the platform as a service (PaaS) cloud service can take
several minutes to complete. Watch the cloud services page. Wait for the Service Status
column to display Created and the Production column to display Running before you continue
to the next task.
Results: You created a storage account and a SQL database, edited the service configuration file, and
deployed the cloud service to the production slot.
Exercise 2: Configuring deployment slots and RDP

 Task 1: Perform a staged deployment of a PaaS cloud service
1. In the Azure classic portal in the Internet Explorer window, on the cloud services page, in the list of
cloud services, click the name of the PaaS cloud service you created in the first exercise.
2. Under Deployment settings, click New staging deployment.
3. In the Upload a package window, in the DEPLOYMENT LABEL box, type AdatumAdsStage.
4. To the right of the PACKAGE box, click FROM LOCAL.
5. Browse to D:\LabFiles\Lab08\Starter\Staging\Package.
6. Click AdatumAds.cspkg, and then click Open.
7. To the right of the CONFIGURATION box, click FROM LOCAL.
8. Browse to D:\LabFiles\Lab08\Starter\Production\Package.
10. Click OK.
11. Click the large arrow pointing to the left to return to the cloud services page.
complete. Watch the cloud services page. Wait for the Staging column to display Running
before you continue to the next task.
 Task 2: Configure RDP access

1. In the Azure classic portal in the Internet Explorer window, on the cloud services page, in the list of
cloud services, click the name of the PaaS cloud service you created in the first exercise.
2. Click CONFIGURE, and then ensure that the PRODUCTION deployment is displayed. If not, click the
PRODUCTION tab.
3. On the toolbar at the bottom, click REMOTE.
4. With (All) in the ROLE drop-down list, select the Enable Remote Desktop check box.
5. In the USER NAME box, type RDPAdmin.
6. In the NEW PASSWORD box, type Pa$$w0rd.

7. In the CONFIRM PASSWORD box, type Pa$$w0rd.
8. In the EXPIRES ON box, select a date one month from today’s date.
9. Click Complete.
10. Wait until the configuration operation is complete.
 Task 3: Test connectivity

1. In the Azure classic portal in the Internet Explorer window, on the CONFIGURE tab of the PaaS cloud
service you created in the first exercise, click DASHBOARD, and then ensure that the PRODUCTION
deployment is displayed. If not, click the PRODUCTION tab.
2. Under quick glance, click SITE URL. The cloud service home page opens in a new Internet Explorer
tab.
3. Leave the new Internet Explorer tab open. You will use it in the next exercise.
4. On the cloud service dashboard, click STAGING.

5. Under quick glance, click SITE URL. The cloud service staging home page opens in a new Internet
Explorer tab.
6. Close the new Internet Explorer tab.

7. At the top of the portal, click INSTANCES, and then click PRODUCTION.
8. In the list of instances, click AdatumAdsWebRole_IN_0.
9. On the toolbar at the bottom, click CONNECT, and then click Open.
10. In the Remote Desktop Connection dialog box, click Connect.
11. In the Password box, type Pa$$w0rd, and then click OK.
12. In the Remote Desktop Connection dialog box, click Yes. The Remote Desktop Protocol (RDP) client
displays the desktop for the first instance of the web role.
13. Close the remote desktop connection.
14. In the Remote Desktop Connection window, click OK.
Results: At the end of this exercise, you will be able to:
• Perform a staging deployment of a PaaS cloud service.
• Enable RDP access to a PaaS cloud service.
• Connect to production and staging instances via HTTP and via RDP.
Exercise 3: Monitoring cloud services

 Task 1: Add metrics to the PaaS cloud service monitoring
1. In the Azure classic portal in the Internet Explorer window, on the INSTANCES tab of the PaaS cloud
service you created in the first exercise, click MONITOR. and then click PRODUCTION.
2. On the toolbar at the bottom, click ADD METRICS.
3. Expand the NETWORK IN section.
4. Select AdatumAdsWebRole Aggregate.

5. Click Yes.
6. In the list of metrics, select the Network In metric for the AdatumAdsWebRole role.
7. To the left of the metric, click the circle to add the metric to the graph.
 Task 2: Create an alert

1. In the list of metrics, select the Network In metric for the aggregate of the AdatumAdsWebRole
role.
2. In the command bar at the bottom, click ADD RULE.
3. In the NAME box, type Network In Alert, and then click Next.
4. In the THRESHOLD VALUE box, type 1.

5. Under ACTIONS, select Specify the email address for another administrator.
6. In the ADDRESS box, type the email address of the service administrator account of your Azure
subscription.
7. Click Complete.
8. After the rule has been created, click DISMISS COMPLETED.
9. Switch to the Internet Explorer tab showing the PRODUCTION deployment of the PaaS cloud service.
Refresh the page several times.
Note: It might take a few minutes before the alert is triggered.
 Task 3: Monitor an active cloud service

1. In the Azure classic portal in the Internet Explorer window, on the MONITOR tab of the PaaS cloud
service you created in the first exercise with the PRODUCTION deployment selected, in the list of
metrics, select the Network In metric for the AdatumAdsWebRole role.
2. On the right on the metric, click 1 rules configured.
3. In the list of rules, click Network In Alert.
4. Inspect the data for the alert.

5. Open a new browser tab in Internet Explorer.
6. On the address bar, type www.outlook.com, and then press Enter.
7. If you are prompted to sign in, use the user name and password of the service administrator account
8. In the list of emails, click Microsoft Azure Alerts.
9. Inspect the details of the alert.

Reset-Azure
Note: This script removes Azure services from your subscription. It is therefore
recommended that you use an Azure trial pass that was provisioned specifically for this course
The script takes 5–10 minutes to reset your Microsoft Azure environment so that it is ready for
the next lab. The script removes all storage, virtual machines, virtual networks (VNETs), cloud
Important: The script might not be able to get exclusive access to a storage account to delete it.
(If this occurs, you will see an error.) If you find objects remaining after the reset script is
complete, you can rerun the Reset-Azure script or use the Azure portal and the Azure classic
portal to manually delete all the objects in your Azure subscription—with the exception of the
default directory.
Results: At the end of this exercise, you will have configured monitoring for a PaaS cloud service with new
metrics and an alert.
L9-69
Module 9: Implementing Azure Active Directory

Lab: Implementing Azure AD
Exercise 1: Administering Active AD
 Task 1: Create directories
1. Ensure that the MSL-TMG1 and 20533C-MIA-CL1 virtual machines are both running, and then sign
in to 20533C-MIA-CL1 as Student with the password Pa$$w0rd.
2. Start Internet Explorer, browse to http://manage.windowsazure.com, and then sign in by using the
3. In the navigation panel on the left, click ACTIVE DIRECTORY.
4. Click New, click DIRECTORY, and then click CUSTOM CREATE.
5. In the Add directory dialog box, enter the following settings, and then click Complete (check mark):

o NAME: Adatum
abcadatum123456). If you get the The domain is not unique message, change the numbers
 Task 2: Activate Azure AD Premium trial

2. Click the Adatum directory.
3. Click Licenses.
4. Click Try Azure Active Directory premium now.

5. In the Activate Azure AD Premium trial pop-up window, click the check mark to confirm the selection.
6. Click the Click here to refresh link, and then verify that Azure AD Premium is activated.
 Task 3: Manage users by using the Azure portal

1. On the active directory page, click Adatum.
2. On the Adatum page, click USERS.
3. Click the ADD USER button at the bottom of the page.
4. In the Tell us about this user dialog box, enter the following settings, and then click Next:

L9-70 Implementing Azure Active Directory
5. In the user profile dialog box, enter the following settings, and then click Next:
o FIRST NAME: Remi
o ROLE: User
6. Click Create.
7. On the Get temporary password page, note the new password.

8. Click Complete (check mark).
9. Click ADD USER.
11. In the user profile dialog box, enter the following settings, and then click Next:
o FIRST NAME: Karen
o LAST NAME: Gruber

o ALTERNATE EMAIL ADDRESS: Type the email address of the Microsoft account that is the Service
Administrator or a Co-Administrator of your Azure subscription.
12. Click Create.
13. On the Get temporary password page, note the new password.
15. At the top-right corner of the page, click your Azure subscription name, and then click Sign Out.
16. On the You have been signed out page, click SIGN IN.
17. On the Microsoft Azure page, click Use another account, and then sign in to Azure by using the
following credentials (where XXXadatumXXX is your unique Adatum number):
o Username: kgruber@XXXadatumXXX.onmicrosoft.com
o Password: Enter the temporary password you noted above.
18. On the Update your password page, in the Current password box, type the temporary password. In
the New password and Confirm password boxes, type Pa$$w0rd123, and click Update password
and sign in.
Note: Although kgruber is a Global Administrator, the attempt to sign in to the portal fails
and the following message appears: We were unable to find any Azure subscriptions where
you are a service administrator or co-administrator. This is because this account is not the
Service Administrator or a Co-Administrator of the Azure subscription. This is by design.
 Task 4: Manage groups by using the Azure portal

1. Start Internet Explorer, browse to https://manage.windowsazure.com, and sign in by using the
3. Click Adatum.
4. Click Configure.
5. Scroll down and in the group management, enable Delegated Group Management Enabled by
selecting Yes.
6. Click Save.
7. Click GROUPS.
8. Click ADD A GROUP.
9. In the Add Group dialog box, enter the following settings, and then click Complete:
o NAME: Sales
o DESCRIPTION: Sales team

10. Click Sales.
11. Click ADD MEMBERS.
12. In the Add members dialog box, click Remi Desforges, and click Complete.
13. Click the Back button.
14. Click ADD GROUP.
o NAME: Marketing
o DESCRIPTION: Marketing employees
16. Click Marketing.
18. In the Add members dialog box, click Remi Desforges, and click Complete (check mark).

20. Click ADD GROUP.
o NAME: Sales and Marketing

o DESCRIPTION: Sales and Marketing employees
22. Click Sales and Marketing.

24. In the Add members dialog box, click the SHOW drop-down box, select Groups, and click the
Confirm button to the right of the SHOW drop-down box.
25. Click Marketing.
26. Click Sales.

 Task 5: Manage users and groups by using Azure PowerShell

1. On the taskbar, right-click Windows PowerShell, and then click Run ISE as Administrator.
2. If a User Account Control dialog box appears, click Yes.
3. In the PowerShell ISE, click File, and then click Open.
4. In the Open dialog box, browse to D:\Labfiles\Lab09\Starter\.
5. Click ExampleCommands.ps1, and then click Open.

6. If the script pane is not visible, on the View menu, click Show Script Pane.
7. In the PowerShell ISE, in the command prompt pane, enter the following command and press Enter:
Connect-MsolService
8. In the Enter Credentials dialog box, sign in as kgruber@XXXadatumXXX.onmicrosoft.com (where

XXXadatumXXX is your unique Adatum domain name) with a password of Pa$$w0rd123, and then
click OK.
9. In the PowerShell ISE, in the script pane, locate the following code:
New-MsolUser -UserPrincipalName mledford@<#Copy your Azure Directory name

here#>.onmicrosoft.com -DisplayName “Mario Ledford” -FirstName “Mario” -LastName
“Ledford” -Password ‘Pa$$w0rd123’ -ForceChangePassword $false -UsageLocation “US”
10. Replace <#Copy your Azure Directory name here#> with your Azure AD directory name.
11. In the PowerShell ISE, in the script pane, select the code that you just edited.
Enter:
Get-MsolUser
New-MsolGroup -DisplayName “Azure team” -Description “Adatum Azure team users”
16. In the PowerShell ISE, in the command prompt pane, enter the following command, and press Enter:
Get-MsolGroup
$group = Get-MsolGroup | Where-Object {$_.DisplayName -eq "Azure team"}

$user = Get-MsolUser | Where-Object {$_.DisplayName -eq "Mario Ledford"}
Add-MsolGroupMember -GroupObjectId $group.ObjectId -GroupMemberType "User"

-GroupMemberObjectId $user.ObjectId
Get-MsolGroupMember -GroupObjectId $group.ObjectId
25. Switch to Internet Explorer.
26. Click USERS, and verify that Mario Ledford appears in the list of users.
27. Click GROUPS, and verify that Azure team appears in the list of groups.
Results: After completing this exercise, you should have created some pilot users and groups in Azure
AD by using the Azure portal and Microsoft Azure Active Directory Module for Windows PowerShell.
You will also enable the Azure AD Premium functionality.
Exercise 2: Configuring SSO

 Task 1: Add directory applications and configure SSO
1. On the Adatum directory page, click APPLICATIONS.
2. Click ADD.
3. In the What do you want to do? dialog box, click Add an application from the gallery.
4. In the Add an application for my organization to use dialog box, in the search box, type
Microsoft, and then press Enter.
5. Click Microsoft Account (Windows Live), in the Display Name text box, type Microsoft Account,
and then click the check mark.
7. Click Assign accounts.
8. From the Show drop-down menu, select All Users, and then click the check mark. In the user list,
click Mario Ledford.
9. At the bottom of the screen, click ASSIGN.
10. In the Assign Users dialog box, select I want to enter Microsoft Account credentials on behalf of
the user.
11. In the Email Address box, type the email address of the Microsoft account associated with your
Azure subscription. In the Password box, type the corresponding password, and then click the check
mark.
12. Above Microsoft account, click the Back arrow.
13. At the bottom of the screen, click ADD.
14. In the What do you want to do? dialog box, click Add an application from the gallery.
15. In the Add an application for my organization to use dialog box, in the search box, type Skype,
and then press Enter.
16. Click Skype, in the Display Name text box, type Skype, and then click the check mark.
18. Click Assign accounts.
19. From the Show drop-down menu, select All Users, and then click the check mark.
20. In the user list, click Mario Ledford.
21. At the bottom of the screen, click ASSIGN.

22. In the Assign Users dialog box, clear I want to enter Skype credentials on behalf of the user, and
then click the check mark.
23. On the top right side of the page, click your Azure account name, and then click Sign out.
 Task 2: Test SSO

1. Close and restart Internet Explorer. In the address box, type
https://account.activedirectory.windowsazure.com/applications, and then press Enter.
2. On the Microsoft Azure page, click Use another account.

3. On the Microsoft Azure page, enter the following credentials (where XXXadatumXXX is your unique
Adatum domain name), and then click Continue:

4. On the applications page, click the ellipsis (...) next to Microsoft Account. Note the options to
update the credentials and report a problem about the Microsoft account.
5. On the applications page, click Microsoft Account.
6. In the Microsoft Account dialog box, click Install Now.
7. On the Internet Explorer bar, click Run.

8. In the Access Panel Extension dialog box, on the Welcome to the Access Panel Extension Setup
Wizard page, click Next.
9. On the Install Access Panel Extension page, click Install.
11. In the Access Panel Extension dialog box, on the Completed the Access Panel Extension Setup
Wizard page, click Finish.
12. On the Internet Explorer bar, click Enable.
14. On the taskbar, click Internet Explorer.

15. In Internet Explorer, in the address box, type

16. On the Microsoft Azure page, enter the following credentials (where XXXadatumXXX is your unique
Adatum domain name), and click Continue.
17. On the applications page, click Microsoft Account, and then in the Microsoft account, enter your
subscription credentials.
Note: If you are prompted to sign in again, use the credentials for your subscription
account.
18. Verify that you signed in to your Microsoft account based on the credentials that have been entered
on behalf of the user.
19. Switch to the Access Panel Applications tab.
20. On the applications page, click Skype; note that you are now prompted for credentials, because you
did not enter any credentials on behalf of the user when configuring SSO.
21. Close the Skype dialog box.
Results: After completing this exercise, you should have installed and configured a test application
and validated the SSO experience.
Exercise 3: Configuring Multi-Factor Authentication

 Task 1: Configure Multi-Factor Authentication
2. In Internet Explorer, in the address box, type https://manage.windowsazure.com, and then press
Enter.
3. On the Microsoft Azure page, click your Azure subscription name; if your Azure subscription is not
shown, click Use another account.
4. On the Sign in page, enter the credentials for the Microsoft account associated with your Azure
subscription, and then click Sign in.
5. In the navigation pane, scroll down, and click ACTIVE DIRECTORY.

6. Click the right arrow next to the Adatum directory.
7. Click CONFIGURE.
8. Under multi-factor authentication, click Manage service settings.
9. If you get a Sign in page, enter the Microsoft account associated with your Azure subscription, and
then click Sign in.
10. On the multi-factor authentication page, click users.

11. In the users list, select the check box for Karen Gruber, and in the quick steps section, click Enable.
12. On the About enabling multi-factor auth page, click enable multi-factor auth.
13. On the Updates successful page, click close.
14. In Internet Explorer, close the Multi-factor Authentication tab.
 Task 2: Test Multi-Factor Authentication

2. In Internet Explorer, in the address box, type

3. On the Microsoft Azure page, click Use another account.
4. On the Sign in page, enter the following credentials (where XXXadatumXXX is your unique Adatum
domain name), and then click Sign in:
Note the following message: Your admin has required that you set up this account for additional
security verification.
5. Click Set it up now.
6. On the additional security verification page, click in the first box, and note the contact method
options.
7. Optional step: If you have access to a mobile phone in the classroom, and have a signal or data
connection, you can complete the additional security verification steps on the additional security
verification page.
Results: After completing this exercise, you should have configured Multi-Factor Authentication for
administrators.
Exercise 4: Configuring SSO from a Windows 10–based computer that is

joined to Azure AD
 Task 1: Join a Windows 10-based computer to Azure AD
2. In Internet Explorer, in the address box, type https://manage.windowsazure.com, and then press
Enter. If required, sign in by using the Microsoft account that is associated with your Azure
subscription.

4. Select the Adatum directory.
6. Scroll down to the devices section.
7. Verify that USERS MAY JOIN DEVICES TO AZURE AD is set to ALL.

8. On MIA-CL1, click the Start button, and then click Settings.
9. In Settings, click Accounts, and then click Work Access.
10. On the Connect to work or school page, click Join or leave an organization. This will redirect you
to the About section of the SYSTEM Settings.
11. Click Join Azure AD.

12. On the What happens next page, click Next.
13. On the Let’s get you signed in page, type the following credentials, and then click Sign in:
14. On the Help us protect your account page, click Set it up now.
15. On the Verify your identity page, from drop-down menu, select Phone call.
16. In the Select your country or region drop-down list, select the country or region where your phone
is registered. In the Phone number text box, type your phone number. Click Next.
17. Press the # key on your phone to complete verification.
18. On the Keep your existing apps working page, click Next.
19. On the Make sure this is your organization page, click Join.
20. On the All finished page, click Finish.
23. Select the Adatum directory.

24. Click Users, and then select the Karen Gruber account.
25. Click the Devices tab.
26. On the You are about to view private user data page, select it is acceptable for admins in my
organization to view this data, and then click OK (confirm selection).
27. From the View drop-down menu, select Devices.
28. Verify that MIA-CL1 is listed.
29. Sign out of MIA-CL1.
 Task 2: Authenticate to Azure from a Windows 10 Azure–joined computer

1. Sign in to MIA-CL1 by using the following credentials:

2. On the Set up a PIN page, click Setup PIN.
3. On the Set up a PIN page, type and retype a four-digit PIN, and then click OK. Note that you cannot
use a common number pattern (such as four identical digits).
4. Start Internet Explorer, and then go to https://portal.office.com.
5. Verify that you are automatically signed in as Karen Gruber by using SSO.
6. Close all open applications and sign out from 20533C-Mia-CL1.


1. Sign in to 20533C-Mia-CL1 as Student with the password Pa$$w0rd.
Enter:
Reset-Azure
subscription.
Azure account.
Results: After completing this exercise, you should have joined the Mia-CL1 computer to Azure AD
and tested the SSO access to the resources in the cloud.
L10-79
Module 10: Managing an Active Directory infrastructure in a

hybrid environment
Lab: Implementing and managing Azure AD
synchronization
Exercise 1: Configuring directory synchronization
 Task 1: Sign in to the Azure VM hosting an Active Directory domain controller
2. Open Internet Explorer and browse to the Azure portal at https://portal.azure.com.
3. When prompted, sign in by using the Microsoft account that is the Service Administrator or a
co-admin of your Azure subscription.
4. On the Hub menu of the Azure portal, click Virtual machines (classic).
5. In the Virtual machines (classic) blade, click AdatumDC1.
6. In the AdatumDC1 blade, click Connect.
7. When prompted whether to open or save the .rdp file, click Save.
8. In the Remote Desktop Connection dialog box, click Connect.
10. In the Windows Security dialog box, enter a user name of ADATUM\Student with the password
Pa$$w0rd123.
 Task 2: Create a new Azure AD tenant and a Global Admin account

1. After the sign-in is complete, click the Windows logo in the lower left corner, and then on the Start
screen, click Internet Explorer.
2. If a Set up Internet Explorer 11 dialog box opens, click Use recommended security, privacy, and
compatibility settings, and then click OK.
3. In Internet Explorer, navigate to the Azure classic portal at https://manage.windowsazure.com.
5. In the Azure classic portal, click ACTIVE DIRECTORY in the navigation bar.
6. Click New, click DIRECTORY, and then click CUSTOM CREATE.

L10-80 Managing an Active Directory infrastructure in a hybrid environment
7. In the Add directory dialog box, provide the following settings, and then click Complete (check
mark):
o NAME: AdatumSync

8. On the adatumsync page, click the USERS tab.
9. Click ADD USER on the command bar.
11. In the USER PROFILE dialog box, provide the following settings, and then click Next:
o FIRST NAME: Sync
o LAST NAME: Admin
12. Click Create.
13. On the Get temporary password page, note the full user name and the temporary password, and
then copy them to Notepad.
15. Click the cogwheel icon in the upper right corner of the Internet Explorer window, click Safety in the
drop-down menu, and then click inPrivate Browsing.
16. In the InPrivate Browsing session, navigate to the Azure classic portal at
17. When prompted, type the full name of the newly created SyncAdmin account, and then click
Continue.
18. When prompted for the password, type the temporary password which you copied to Notepad, and
then click Sign in.
19. On the Update your password page, in the Current password text box, type the temporary
password, in the New password and Confirm password text boxes, type Pa$$w0rd, and then click
Update password and sign in.
20. On the No subscriptions found page, click SIGN OUT.

 Task 3: Install Azure AD Connect with custom settings

1. Open an Internet Explorer session and browse to https://www.microsoft.com/en-us/download
/details.aspx?id=47594.
2. On the Microsoft Azure Active Directory Connect page, click the cogwheel in the upper right
corner of the Internet Explorer window and select Internet options from the drop down menu.
3. In the Internet Options dialog box, click the Security tab.
4. Click Trusted sites, and then click Sites.
5. In the Add this website to the zone text box, replace the current entry with
https://*.microsoft.com, and then click Add.
6. Click Close, and then click OK.
7. Back on the Microsoft Azure Active Directory Connect page, click Download.
8. In the pop-up window, click Save.
9. After the download is complete, click Open Folder.
10. In the File Explorer window, double-click AzureADConnect.msi to start the installation.
Continue.
12. On the Express Settings page, click Customize.
13. On the Required Component page, review the options, and then click Install.
14. On the User sign-in page, verify that Password Synchronization is selected, and then click Next.
15. On the Connect to Azure AD page, provide the credentials of the newly created SyncAdmin Azure
AD Global Admin, and then click Next:
o User name: SyncAdmin@yourdomainname.onmicrosoft.com
16. Note the message The directory associated with this account has no verified domains. You
should verify a domain in Azure AD before continuing., and then click Next.
17. On the Connect your directories page, verify that the adatum.com forest is selected, under user
name, type ADATUM\Student with the password Pa$$w0rd123, and then click Add Directory.
18. Verify that under Configured Directories, adatum.com is listed, and then click Next.
19. On the Domain and OU filtering page, select the Sync selected domains and OUs check box,
expand the adatum.com entry, clear all check boxes with exception of the one next to the Accounts
organization unit, and then click Next.
20. On the Uniquely identifying your users page, verify that Users are represented only once across
all directories is selected, and then click Next.
21. On the Filtering page, verify that Synchronize all users and devices is selected, and then click Next.
22. On the Optional feature page, verify that Password hash synchronization is selected, and then
click Next.
23. On the Ready to configure page, verify that Start synchronization process as soon as the
configuration completes is selected, and then click Install.
Note: Installation might take 5-10 minutes.

L10-82 Managing an Active Directory infrastructure in a hybrid environment
24. On the Configuration complete page, click Exit to close Azure AD Connect.
Note: You might need to wait a few minutes for the initial synchronization to complete.
25. Switch back to the Azure classic portal in the Internet Explorer window.
26. In the Azure classic portal, navigate to the adatumsync Active Directory page, click USERS, and then
confirm that the list of users includes all the names from the Accounts organizational unit (OU).
Results: After completing this exercise, you should have installed and configured Azure AD Connect,
and you should have it ready for test synchronization.
Exercise 2: Synchronizing directories

 Task 1: Modify attributes of an Active Directory user and Initiate manual
synchronization
1. On AdatumDC1, switch to the Server Manager window, and from the Tools menu, open the Active
Directory Administrative Center.
2. Click adatum (local), and then double-click Accounts.
3. After the Accounts OU content is displays, double-click the Beverly Beach (bbeach) account.
4. In the Beverly Beach (bbeach) window, make changes to the following fields, and then click OK:
o Job Title: VP
o Department: Marketing
5. On AdatumDC1, on the taskbar, right-click the Windows PowerShell shortcut, right-click Windows
PowerShell on the menu and then click Run as administrator.
6. At the command prompt in the Windows PowerShell command-line interface, type the following
command, and then press Enter:
Get-ADSyncScheduler
Note: Get-ADSyncScheduler displays the current configuration settings for

synchronization with Azure AD.
Start-ADSyncSyncCycle -PolicyType Delta
8. Wait until synchronization completes before proceeding to the next step.
9. Switch back to the Azure classic portal in the Internet Explorer window.
10. Click the USERS tab on the adatumsync page.
11. Click the Beverly Beach entry.
12. On the Beverly beach page, click WORK INFO.

13. Verify that the JOB TITLE and the DEPARTMENT entries match the ones you configured for the
Active Directory account. If you do not see any changes, wait for a few minutes, and then refresh the
page.
14. Close the AdatumDC1 remote desktop session, and then click OK when prompted.

1. On MIA-CL1, close all open applications without saving any files.
Reset-Azure
subscription.
Note: This script might remove Azure services in your subscription. We therefore
recommend that you use an Azure trial pass that was provisioned specifically for this course,
The script will take 5-10 minutes to reset your Azure environment and make it ready for the
next module. The script removes all storage, virtual machines, virtual networks, cloud
Important: The script might not be able to get exclusive access to a storage account to
delete it; if this occurs, you will see an error. If you find objects remaining after the reset
script is complete, you can rerun the Reset-Azure script, or you can use the Azure classic
portal to delete all the objects in your Azure subscription manually, with the exception of the
default directory.
Results: After completing this exercise, you should have changed attributes on a user account, and
then forced synchronization.
L11-85
Module 11: Implementing Azure-based management and

automation
Lab: Implementing Automation
Exercise 1: Configuring Automation accounts
 Task 1: Create an Automation account
Setup-Azure script has completed.
2. Start Internet Explorer and browse to https://portal.azure.com. When prompted, sign in by using
the Microsoft account that is the Service Administrator or Co-Administrator of your Azure
subscription.
3. On the Hub menu, click New, and then click Management.
4. In the Management blade, click Automation.

5. In the Add Automation Account blade, specify the following:
o Name: LabAutomationAccount
o Resource group: create a new resource group named AutomationLabRG

o Region: an Azure region that you chose when running the provisioning script
o Account Options: leave at the default setting. This will create a tutorial runbook in the new
account
o Pin to dashboard: Leave enabled
6. Click Create.
7. Wait for the Automation account to be provisioned. This should take less than a minute.
 Task 2: Create an Azure AD user

1. In the Azure portal, click Browse on the Hub menu on the left side of the page, and then click Active
Directory. This should automatically open another Internet Explorer tab with the view of your
default directory.
2. On the default directory page, click USERS.
3. Click ADD USER in the command bar at the bottom of the page.
4. On the Tell us about this user page of the ADD USER Wizard, specify the following:
o USER NAME: LabAutomationUser

5. On the user profile page of the ADD USER Wizard, in the DISPLAY NAME box, type
LabAutomation User.
6. In the ROLE drop-down list, ensure that User is selected (do not enable Multi-Factor Authentication).
Note that you are creating an organizational account, and you will make this account a co-
administrator of your Azure subscription.
L11-86 Implementing Azure-based management and automation
7. Click Next.
8. On the Get temporary password page of the ADD USER Wizard, note the full user name (including
the part after the @ sign), and then copy it to Notepad.
9. Click create and note the temporary password shown in the NEW PASSWORD text box. Click the
Copy icon to the right of the text box. If prompted, click Allow access and click the Copy icon again.
Paste the copied password to Notepad.
10. Click Complete.
11. Click the large blue arrow pointing to the left.

12. In the navigation bar on the left side, scroll down to the bottom, and then click SETTINGS.
13. Click ADMINISTRATORS.
14. At the bottom of the page, click ADD.
15. In the EMAIL ADDRESS box, type the name of the new user that you created that you copied to
Notepad in the format LabAutomationUser@<domain>.
16. Under SUBSCRIPTION, select your current Azure subscription, and then click OK.
17. At the top right of the page, click your current account name, and then click Sign out.
18. On the You have been signed out page, click SIGN IN.
19. On the Microsoft Azure sign-in page, click Use another account.
20. On the Sign in page, enter the newly created user’s credentials, and then click Continue.
21. When prompted for the password, type the user’s password that you copied to Notepad, and then
click Sign in.
22. On the Update your password page, in the Current password text box, type the temporary
password.
23. In the New password and Confirm password text boxes, type Pa$$w0rd, and then click Update
password and sign in.
24. If the Sign in page appears, enter your new password, and then click Sign in.
25. Close the WINDOWS AZURE TOUR dialog box.
26. At the top right of the page, click the currently signed-in user account name, and then click Sign out.
 Task 3: Create Automation assets

1. Switch back to the Azure portal. On the Hub menu, click Browse, and then click Automation
Accounts.
2. In the Automation Accounts blade, click the Automation account you created in Exercise 1, Task 1.
3. In the LabAutomationAccount blade click the ASSETS tile.
4. On the Assets blade, notice that you have several Windows PowerShell modules included in your
account by default.
5. Click Credentials.
6. In the Credentials blade, click Add a credential.

7. In the New Credential blade, specify the following:
o Name: PSCredential
o Description: Lab Automation User (Co-Administrator)
8. Click Create.
9. Close the Credentials blade.

10. Click the Variables tile.
11. In the Variables blade, click Add a variable.
12. In the New Variable blade, specify the following:
o Name: SubscriptionName
o Description: Subscription Name
o Type: String
o Value: name of your subscription
o Encrypted: No
13. Click Create.

14. Repeat the steps 12 and 13 to create four string variables. For each variable, specify the following
name and value (leave the description blank):
o Name: AdminName
Value: Student
o Name: AdminPassword
Value: Pa$$w0rd
o Name: Location
Value: Location: the name of the Azure region that you used when running the provisioning script
at the beginning of this module
o Name: Network
Value: ADATUM-HQ-VNET
o Name: Subnet
Value: Subnet-1
15. Back on the Assets blade, click the Schedules tile.
16. In the Schedules tile, click Add a schedule.

L11-88 Implementing Azure-based management and automation
17. In the New Schedule blade, specify the following:
o Name: EndOfDay
o Recurrence: Daily
o Expires: Never
18. Click Create.
19. Close the Schedules blade.
20. Close the Assets blade.
Results: After completing this exercise, you should have configured a new Microsoft Azure Automation
account, and created a new Microsoft Azure Active Directory (Azure AD) organizational account to use as
an Automation Credential asset.
Exercise 2: Creating runbooks

 Task 1: Import a runbook
1. In the Azure portal, in the blade displaying your Automation account, click the Runbooks tile.
2. In the Runbooks blade, click Add a runbook.
3. In the Add Runbook blade, click Import an existing runbook.
4. In the Import blade, specify the following:

o Runbook file: D:\Labfiles\Lab11\Solution, select New-StorageAndVMs.ps1
o Runbook type: PowerShell Workflow
o Name: New-StorageAndVMs
o Description: leave blank
5. Click Create.
6. In the Runbooks blade, click New-StorageAndVMs.

7. In the New-StorageAndVMs blade, click Edit.
8. In the Edit PowerShell Workflow Runbook blade, review the content of the PowerShell workflow.
 Task 2: Publish and execute a runbook

1. In the Edit PowerShell Workflow Runbook blade, click Publish.
2. When prompted to confirm, click Yes. You will be automatically redirected to the New-
StorageAndVMs blade.
3. Click Start.
4. When prompted to confirm, click Yes. You will be automatically redirected to a blade displaying the
current job, with a name consisting of the combination of the runbook name and timestamp of its
invocation.
5. Click Output tile.

6. Monitor the runbook execution. Wait until the job completes.

Reset-Azure
subscription.
Note: This script will remove Azure services in your subscription. We therefore recommend
own Azure account.
The script will take 5-10 minutes to reset your Microsoft Azure environment to be ready for the
next lab.
The script removes all storage, virtual machines (VMs), virtual networks, cloud services, and
resource groups.
(if this occurs, you will see an error). If you find remaining objects after the reset script is
complete, you can rerun the Reset-Azure script, or use the Azure portal and Azure classic portal
to delete all the objects in your Azure subscription manually—with the exception of the default
directory.
Results: After completing this exercise, you should have imported, published, and executed a PowerShell
workflow–based runbook that deploys two virtual machines in parallel.

20533C TrainerHandbook PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

20533C TrainerHandbook PDF

Uploaded by

Copyright:

Available Formats

MCT USE ONLY.

STUDENT USE PROHIBITED

Microsoft and the trademarks listed at http://www.microsoft.com/trademarks are trademarks of the

Product Number: 20533C

Part Number: X20-97615

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

Marjan Stamatovski: Content Developer

Jason Kellington: Content Developer

Telmo Sampaio: Technical Reviewer

Lesson 1: Cloud technology overview 1-2

Lesson 2: Overview of Azure 1-6

Lesson 3: Managing Azure with the Azure portal 1-17

Lesson 4: Managing Azure with Windows PowerShell 1-21

Lesson 5: Overview of Azure Resource Manager 1-28

Lesson 6: Azure management services 1-33

Lab: Managing Microsoft Azure 1-38

Module Review and Takeaways 1-43

Module 2: Implementing and managing Azure networking

Lesson 2: Implementing and managing virtual networks 2-17

Lab A: Using a deployment template and Azure PowerShell to implement

Lesson 3: Configuring Azure virtual network 2-29

Lesson 4: Configuring virtual network connectivity 2-39

Lab B: Configuring connectivity between IaaS v1 and IaaS v2 2-58

Module Review and Takeaways 2-63

Module 3: Implementing virtual machines

Lesson 1: Overview of IaaS v2 virtual machines 3-2

Lesson 2: Planning for Azure Virtual Machines 3-7

Lesson 3: Deploying IaaS v2 virtual machines 3-15

Lab A: Creating IaaS v2 virtual machines in Azure 3-22

Lesson 4: Authoring Azure Resource Manager templates 3-25

Lesson 5: Overview of IaaS v1 virtual machines 3-34

Lab B: Deploying IaaS v2 virtual machines by using Azure Resource Manager

Module Review and Takeaways 3-42

Module 4: Implementing virtual machines

Lesson 1: Configuring virtual machines 4-2

Lesson 2: Configuring virtual machine disks 4-11

Lesson 3: Managing and monitoring Azure virtual machines 4-17

Lesson 4: Managing IaaS v1 virtual machines 4-28

Lab: Managing Azure virtual machines 4-32

Module Review and Takeaways 4-39

Module 5: Implementing Azure App Service

Lesson 1: Introduction to App Service 5-2

Lesson 2: Planning app deployment in App Service 5-12

Lesson 3: Implementing and maintaining web apps 5-16

Lesson 5: Monitoring web apps and WebJobs 5-33

Lesson 6: Implementing mobile apps 5-38

Lab: Implementing web apps 5-50

Module Review and Takeaways 5-57

Module 6: Planning and implementing storage, backup, and recovery services

Lesson 1: Planning storage 6-2

Lesson 2: Implementing and managing Azure Storage 6-10

Lesson 4: Implementing Azure Backup 6-27

Lesson 5: Planning and implementing Azure Site Recovery 6-34

Lab: Planning and implementing Azure Storage 6-40