Lab Azure

MCT USE ONLY.
STUDENT USE PROHIBITED

2-2 Implement and Manage Virtual Networks
Lesson 1
Planning Virtual Networks
As with on-premises networks, Microsoft Azure networks need to be planned carefully to ensure that they
work as expected. However, you should find that your knowledge of planning on-premises networks
translates relatively simply into the Microsoft Azure environment.
Lesson Objectives
After completing this lesson, you will be able to:
Understand how virtual networks can be used to support virtual machines and PaaS cloud services.
Describe the overall functioning of virtual networking in Microsoft Azure.

List the features supported by Azure virtual networks.
Explain how on-premises computers can connect to VMs in an Azure virtual network.
Plan a VPN connection from one Azure virtual network to another.
Design IP address space and subnet allocation to manage host numbers.
Plan for effective name resolution in Microsoft Azure virtual networks.
Demonstration: Preparing the Environment

Perform the following tasks to prepare the lab environment. The Azure services you will use in the lab will
be described in this module while the environment is being configured.
Important: The scripts used in this course may delete any objects that you have in your
subscription. For this reason, you should complete this course against 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 avoids
confusion in labs and 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 any current Azure subscription and account details 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 also which Azure region is second closest. You will need this information during
the lab.
MCT USE ONLY. STUDENT USE PROHIBITED
Implementing Microsoft Azure Infrastructure Solutions 2-3
Demonstration Steps
Sign in to Your Microsoft Azure Subscription
1. Ensure that the MSL-TMG1 and 20533B-MIA-CL1 virtual machines are both running, and then log on
to 20533B-MIA-CL1 as Student with the password Pa$$w0rd.
2. You should already have created a Microsoft Azure trial subscription. If you have not done so, follow
the instructions in D:\Creating a Microsoft Azure Trial Subscription.htm. Provisioning may take
several hours.
3. When your trial subscription has been provisioned, in Internet Explorer, browse to
http://azure.microsoft.com, click Portal, and sign in using the Microsoft account that is associated
with your Azure subscription. Close any initial "welcome" messages and password storage messages.
4. At the top right, click your Microsoft account name and click Switch to new portal. If you are
prompted to sign in, use the Microsoft account that is associated with your subscription. Then, in the
new tab that is opened, close any initial "welcome" messages for the new portal.
Prepare the Azure Environment
1. On the taskbar, right-click Microsoft Azure PowerShell, and then click Run as administrator. In the
User Account Control dialog, click Yes.
2. Type the following command, and then press Enter:
Setup-Azure
3. At the prompt, type the module number, and then press Enter.
4. Confirm your selection, and then press Enter.
5. When prompted, sign in using the Microsoft account associated with your Azure subscription.
Note: This script may remove Azure services in your subscription. It is 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 a few seconds to configure your Microsoft Azure environment, ready for the lab at the
end of this module.
6. When the script is complete, close PowerShell and Internet Explorer.
Virtual Networks as a Component of Azure

Virtual Networks (VNets) in Microsoft Azure are
network overlays that you can use to configure
and control connectivity between virtual machines
(VMs) and PaaS cloud service roles. You can use
both VMs and PaaS cloud services without VNets
but, when you organize them into VNets, you
enable them to communicate directly on an
isolated network and can set IP addressing
schemes and name resolution settings.
Virtual networks (VNets) in Windows Azure also enable you to extend your on-premises networks into the
cloud. To build such a configuration, you must connect a Virtual Private Network (VPN) from your on-
premises computers or networks to the Azure VNet. Alternatively, you can use ExpressRoute to provide a
connection to an Azure VNet that does not cross the Internet. In this way, you can enable on-premises
users to access Azure services as if they were physically located on-premises in your own datacenter.
VNets are often used to support Virtual Machines (VMs) by grouping them into subnets. However, you
can also create PaaS Cloud Services in VNets for the same reason. In addition, this module mentions
Traffic Manager because you can use it to load balance traffic between VMs or cloud services in VNets.
VMs, PaaS cloud services and Traffic Manager are discussed in later modules in this course.
Overview of Virtual Networks

A major driver for the adoption of cloud services,
such as Azure, is to enable IT departments to
move server resources into the cloud. This can
save companies money 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 may not
have the expertise to maintain their own robust
infrastructure.
You can create VMs in Azure without using VNets.

Each VM must be placed 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 IaaS cloud services can only communicate through cloud service endpoints that have specific
port numbers. VMs can only communicate with PaaS cloud services though endpoints.
This situation becomes more flexible when you consider VNets: A VM in a VNet can communicate directly
with any other VM in the VNet, even if it is in a different IaaS cloud service. VNets are the only way to
enable direct communication between a VM and a PaaS cloud service. You can also control the IP
addresses assigned to VMs and PaaS cloud service within a VNet and assign DNS servers for name
resolution.
When you move a server into 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 barriers. A VPN can connect your on-premises
network to and Azure VNet 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.
You can use similar private IPv4 address ranges in Azure VNets that you use on-premises:
10.x.x.x
172.16.x.x 172.31.x.x
192.168.x.x
You must carefully plan the IP addressing scheme. You will learn more about this planning later in this
lesson. Azure also supports the customization of DNS servers to ensure that on-premises computers can
resolve the IP address of virtual servers in the VNet from a name, and that virtual servers can resolve the IP
address of on-premises computers.
To connect to an Azure VNet from an on-premise network, you can use virtual private networks (VPNs) to
connect across the Internet, or an ExpressRoute connection:
A Point-to-Site VPN. This is a VPN that connects a single computer to a VNet. To create this
connection, you must configure each on-premises computer that you want to use the resources in the
VNet.
A Site-to-Site VPN. This is a VPN that connects an on-premises network, and all its computers, to a
VNet. To create this connection, you must configure a gateway and IP routing in the on-premises
network but 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. By using ExpressRoute, you can increase security, reliability, and bandwidth.
You can also create a VPN that connects two Azure VNets. These are called VNet-to-VNet connections.
You will learn more about these connection methods in Lesson 3 Configuring Connections to Virtual
Networks.
Whenever you use a VPN to connect to a VNet, a virtual gateway is required in the VNet. The virtual
gateway routes traffic between VMs and PaaS cloud services in the VNet and computers at the other end
of the connection.
Virtual Network Features

Virtual Networks in Azure have a range of features
that help you to group virtual machines and cloud
services and connect to VNets from on-premises
or internet-connected machines.
VNets for Cloud Services and Virtual

Machines
Once you have created a VNet, you can place new
VMs and PaaS Cloud Services into the new VNet.
VMs and cloud services within the same VNet can
communicate directly without going through an
endpoint or virtual gateway.
IP Addressing in VNets
VMs and PaaS cloud service roles in a single VNet require a unique IP address in the same way as clients
in an on-premise subnet do. This enables these VMs and cloud service roles to communicate with each
other. There are two types of IP addresses used in an Azure VNet:
DIPs. A DIP is a dynamic internal IP address. This address is used by VMs in the VNet to communicate
with other VMs in the same VNet. When you have connected a VPN to an Azure VNet, on-premises
clients communicate with VNet VMs by using DIPs.
VIPs. A VIP 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.
Azure assigns DIPs by using the DHCP protocol. DHCP leases are infinite in duration, so IP addresses are
stable. However, in some circumstances, such as when a VM has been placed into the Stopped
(Deallocated) state, a DIP may change.
If you are using a VPN to connect on-premises computers to the VNet, you must ensure that the on-
premises IP address and the VNet DIP addresses do not conflict. You will learn how to plan a non-
conflicting IP addressing scheme later in this lesson.
You can ensure a VM always has the same DIP address by setting a static internal IP address (also known
as a persistent private IP address) in PowerShell. Start by testing that the IP address you want to reserve is
not already in use, then use the Set-AzureStaticVNetIP 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 within Windows. This method must not be used for VMs within
Azure because it will result in dropped connections and connectivity failures. Instead use Set-
AzureStaticVNetIP as described above.
Similarly, you can also ensure that the VIP 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"
Note: You will learn more about creating VMs, both in the portals and in PowerShell, in
Module 3.
Most of the time, VIPs are the only external IP addresses you need to assign. A VIP is assigned to an IaaS
cloud service and endpoints are used to specify one or VMs that receive incoming traffic to the VIP.
Alternatively a VIP can be assigned to a PaaS cloud service and endpoints used to specify the cloud
service role that receives incoming traffic.
However, in some cases you may 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 FTP in Passive Mode, the client negotiates the port number to use for transferring files. In such
cases, assign an instance-level Public IP (PIP) to the VM.
In this example, the script obtains an existing VM and then assigns a PIP to it.
Assigning an Instance-Level PIP to a VM

Get-AzureVM -ServiceName FTPService -Name FTPVM1 | Set-AzurePublicIP -PublicIPName ftpip | Update-
AzureVM
You can also configure multiple network interface cards (NICs) for Azure VMs. In this case, each NIC
receives a separate DIP and you can utilize the NICs to isolate communication. For more information
about multiple NICs, see the following link:
Create a VM with Multiple NICs

http://go.microsoft.com/fwlink/?LinkID=522618
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 but in some cases, you may need to configure an external DNS system to
resolve IP addresses with an Azure VNet.
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 VNet through a VPN, an on-premises computer could not resolve the DIP of a
VM in an Azure VNet until you configured the DNS servers with a record for the VM. You will learn more
about configuring name resolution later in this lesson.
Azure Load Balancer and Internal Load Balancer

External clients use a VIP address to communicate with a VM. This VIP is associated with an IaaS cloud
service that may be in an Azure VNet. You define endpoints on the cloud service to enable external clients
to connect to specific VMs within the cloud service. By default, an endpoint is associated with a single VM.
To increase availability and scalability, you can create two or more VMs in the same IaaS cloud service that
publish the same application. For example, if 3 VMs host the same website, you may want to distribute
incoming traffic between them and ensure that, if one VM fails, traffic is automatically distributed to the
other two.
You can use a load balanced set to enable this traffic distribution between VMs in a single cloud service.
In this configuration a single endpoint is shared between multiple VMs. The Azure Load Balancer
automatically randomly distributes requests across those VMs as they arrive at the endpoint.
Now consider the case where one VM in a VNet communicates with other VMs in the same VNet. For
example, a web server may 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 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
endpoint.
Traffic Manager
Traffic Manager is another load balancing solution included within Azure that can load balance between
endpoints located in different Azure regions. These endpoints can include those on IaaS cloud services
that connect to virtual machines, those on PaaS cloud services that connect to roles, and those on Azure
websites. You can configure this load balancing to support failover or to ensure that users connect to an
endpoint that is close to their physical location for higher performance. You will learn how to configure
Traffic Manager in Module 5.
Regional VNets
All new VNets are regional VNets. This means they can span a complete Azure region or datacenter. This
differs from the original VNets in Azure, which were restricted to a single affinity group. If you have older
VNets in your subscription, these may be tied to an affinity group. However, over time all VNets will be
migrated to regional VNets and their ties to specific affinity groups will be removed.
Regional VNets support some features that affinity group VNets do not. These include:
Reserved IP Addresses
Internal Load Balancing
Instance-Level Public IP Addresses
More VM Sizes
Connecting to Virtual Networks

Before you can use a VM or PaaS cloud service
within an Azure VNet, you must connect to that
VNet. There are several ways to make this
connection.
Cloud-Only Virtual Networks

You can choose not to make any kind of virtual
private network (VPN) connection to a VNet.
Instead, when you create a VM or cloud service,
you can specify endpoints that external clients can
connect to. An endpoint is a VIP and a port
number. Therefore an endpoint can be used only
for a specific protocol, such as connecting a
Remote Desktop Protocol (RDP) client or browsing a website.
These VNets are known as cloud-only virtual networks. A dynamic routing gateway is not required in the
VNet.
Endpoints are published to the Internet, so they can be used by anyone with an Internet connection,
including your on-premises computers.
Point-to-Site VPNs
A simple way to connect a VPN to an Azure VNet is to use a Point-to-Site VPN. In these VPNs, you
configure the connection on individual on-premises computers. No extra hardware is required but you
must complete the configuration procedure on every computer that you want to connect to the VNet.
Point-to-site VPNs can be used by the client computer to connect to a VNet from any location with an
Internet connection. Once the VPN is connected, the client computer can access all VMs and cloud
services in the VNet as if they were running on the local network.
You will learn how to configure a Point-to-Site VPN in Lesson 2.

Site-to-Site VPNs
To connect all the computers in a physical site to an Azure VNet, you can create a Site-to-Site VPN. In this
configuration, you do not need to configure individual computers to connect to the VNet, instead you
configure a VPN device, which acts as a gateway to the VNet. You must also configure routing tables to
forward traffic to the VNet. Once these steps are completed, all computers in the local on-premises
network can connect to VMs and services in the VNet as if they were local resources.
You can use a Windows Server 2012 computer running RRAS as a gateway to the VNet. Alternatively,
there are a range of third-party VPN devices that are known to be compatible. If you have a VPN device
that is not on the known compatible list, you may be able to use it if it satisfies the list of gateway
requirements. To check the compatible VPN device list and requirements list, see:
About VPN Devices for Virtual Network

ExpressRoute
ExpressRoute is a service that enables Azure customers to create a dedicated connection to Azure, which
does not connect through the public Internet. This contrasts with VPNs, which use encryption to tunnel
securely through the public Internet.
Because ExpressRoute connections are dedicated, they can offer faster speeds, higher security, lower
latencies, and higher reliability than VPNs. To learn more about Express Route, see:
ExpressRoute Technical Overview

VNet-to-VNet Connections
As well as connecting an on-premises network to
an Azure VNet by using a VPN, you can also use a
VPN to connect two or more Azure VNets. Such
connections are termed VNet-to-VNet VPNs. The
connected VNets can be in different regions and
even in different Azure subscriptions.
Comparing Site-to-Site and VNet-to-

VNet VPNs
Functionally and conceptually, a VNet-to-VNet
connection is the same as a Site-to-Site
connection except that both ends of the
connection are VNets. VMs and cloud service
components in each VNet can communicate as if they were on the same VNet. However, the
configuration of a VNet can be a confusing process because you must complete similar tasks at both ends
of the connection.
To understand the configuration, first consider a Site-to-Site VPN. You must configure:
An IP addressing scheme in the VNet.
The range of IP addresses that are available on the local, on-premises subnet.
A gateway in the local subnet.
A virtual gateway in the VNet.
Because the virtual gateway is configured with the IP addresses in the VNet and the IP addresses in the
local network, it can route packets from Azure to the local network.
Now consider a VNet-to-VNet VPN that connects a VNet in the West US region to a VNet in the North
Europe region. You must configure:
An IP addressing scheme in the West US VNet.
An IP addressing scheme in the North Europe VNet.

A virtual gateway in the West US VNet.
A virtual gateway in the North Europe VNet.
When you configure the virtual gateway in West US, the IP address range that you provide for the Local
Network is actually the range for North Europe VNet. Similarly for the virtual gateway in North Europe,
the IP address range that you provide for the Local Network is actually the range for West US VNet. This
can confuse administrators because neither Local Network is in fact an on-premises network.
Note: You will configure a VNet-to-VNet VPN connection in the lab.
Designing IP Address Space and Subnet Allocation in Azure

Virtual Networks
You can control the DIPs assigned to VMs and
cloud services within an Azure VNet by specifying
an IP addressing scheme. Planning an IP
addressing scheme within Azure VNets is much
like planning an IP addressing scheme on-
premises. The same ranges are often used and the
same rules applied. However there are conditions
that are unique to Azure VNets.
Private Address Spaces

The RFC 1918 standard defines three private
address spaces that are never used for addressing
on the Internet. Administrators use these ranges
behind Network Address Translation (NAT) devices to ensure unique addresses used within intranets
never prevent communication with Internet servers. These three address spaces are the only ones that are
supported within an Azure VNet. The address spaces are:
10.0.0.0/8. This address space includes all addresses from 10.0.0.1 to 10.0.0.255.
When you specify an address space for a VNet, you usually specify a much smaller range within one of the
private address spaces. For example, if you specified the address space 10.1.1.0/24, it means that all
addresses from 10.1.1.1 to 10.1.1.255 should be routed into your VNet.
In a cloud-only virtual network, you can specify any address range from the RFC 1918 private spaces.
However, if you will connect to the VNet with a VPN or ExpressRoute, you must ensure that the address
space is unique and does not overlap any of the ranges that are already in use on-premises or in other
VNets.
Best Practice: Always plan to use an address space that is not already in use in your
organization, either on-premises or in other VNets. Even if you plan for a VNet to be cloud-only,
you may want to make a VPN connection to it later. If there is any overlap in address spaces at
that point, you will have to reconfigure or recreate the VNet.
Choosing Subnets
You must also sub-divide the VMs and cloud services in your VNet by providing one or more subnets. The
range you specify for a subnet must be completely contained within its parent VNets 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.
Use Static Internal IP Addresses

Because clients use DNS to resolve a name to an IP address, many VMs and services can receive new DIPs
without interrupting their service to users. In addition, because DHCP leases are infinite in Azure VNets, IP
addresses rarely change. However, sometimes an IP change does happen. For example, if a new VM is
created while another VM is in the Stopped (Deallocated) state, the new VM may take the old VMs
original address.
If you expect IP address change to cause problems for server, you can use a static internal IP address for
that VM. For example, a DNS server should have a static IP address, because clients may not be able to
locate it if its address changes. See the topic Virtual Network Features in this lesson for instructions on
setting a static IP address.
Planning for Name Resolution in Azure Virtual Networks

Name resolution is the process by which a
computer name is resolved to an IP address. A
computer can use the IP address to connect to the
named computer by using the IP address that the
user may find it difficult to remember.
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 connect.
Consider the following situations:
VMs in the same cloud service. VMs can resolve the names of all other VMs in the same cloud service
automatically by using the internal Azure name resolution.
VMs in the same VNet. If the VMs are in different cloud services but within a single VNet, those VMs
can resolve IP addresses for each other by using the internal Azure name resolution service and their
Fully Qualified Domain Names (FQDNs). This is supported only for the first 100 cloud services in the
VNet. Alternatively, use your own DNS system to support this scenario.
Between VMs in a VNet and on-premises computers. To support this scenario you must use your own
DNS system.
Between VMs in different VNets. To support this scenario you must use your own DNS system.
Between on-premises computers and public endpoints. If you publish an endpoint from a VM in an
Azure VNet, the Azure-provided external name resolution service will resolve the public VIP. This also
applies for any internet-connected computers that are not on your premises.
Note: If two VMs are deployed in different IaaS cloud services but not in a VNet, they
cannot communicate at all, even by using DIPs. Therefore name resolution is not applicable.
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 VNet or
have VM register their addresses with an on-premises DNS server. Your DNS server must meet the
following requirements:
The server must support Dynamic DNS (DDNS) registration.
The server must have record scavenging switched off. Because DHCP leases in an Azure VNet are
infinite, record scavenging can remove records that have not been renewed but are still correct.
The server must have DNS recursion enabled.
The server must be accessible on TCP/UDP port 53 from all clients.

Lesson 2
Implementing and Managing Virtual Networks
In this second lesson, you move on from the planning process to review how to create and manage the
virtual networks that you create. There are two main ways to configure virtual networks: the Microsoft
Azure Portal and network configuration files.
Lesson Objectives
After completing this lesson, you should be able to:
Create and configure virtual networks by using the Microsoft Azure Management Portal.
Navigate the schema of a network configuration file.

Export and import network configuration files in to configure the virtual networks in an Azure
subscription.
Create and modify a virtual network by using a network configuration file.

Create a virtual machine and deploy that VM into a virtual network.
Creating Virtual Networks using the Management Portal

To create a virtual network, you can either use the
full portal or upload a network configuration file.
A network configuration file is an XML file with a
specific schema.
Note: At the time of writing, the preview

portal does not support creating virtual networks,
although you can browse a virtual networks
configuration.
To create a cloud-only virtual network in the full

portal, following these steps:
1. In the navigation menu 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 VNet.
4. In the Location drop-down list, select a location near your users, and then click the Next arrow.
5. Under DNS SERVERS, enter 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 may be able to use Azure internal name
resolution and leave this value blank.
6. Click the Next arrow.
7. On the Virtual Network Address Spaces page, add the private address spaces and subnets that you
have planned, and then click Complete.
Note: If you want to create a VPN connection to the VNet, you can either configure the
VPN as part of the VNet creation wizard, or add the VPN later. In the next lesson, you will learn
how to configure VPNs.
Network Configuration Files

The configuration of an Azure VNet can be
summarized in an XML file called a network
configuration file. These files can include the
following settings:
The name and location of the VNet.
DNS servers for the VNet.
IP private addresses spaces for DIPs in the

VNet.
Subnets within the private address spaces.
The IP address of the virtual gateway that

connects to a VPN.
The following XML shows a complete network configuration file for a VNet 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>
Exporting and Importing Network Configuration Files

In the portal, you can download the network
configuration file by clicking Export in the toolbar
for the DASHBOARD page. You can also do this in
PowerShell by issuing the Get-AzureVNetConfig
cmdlet. You can make changes to this file and
then apply them by uploading the configuration
file with the Set-AzureVNetConfig cmdlet.
The following PowerShell commands export a

networking configuration from Azure and then
import a different configuration file.
Exporting and Importing a Network Configuration

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

Set-AzureVNetConfig -ConfigurationPath C:\configs\UpdatedConfig.xml
Demonstration: Creating and Modifying a Network Using

a Configuration File
In this demonstration, you will see how to:
Open a previously created network configuration file.
Import a network configuration file into Azure.
Update a network configuration file offline.

Import a new configuration file to apply your changes.
Demonstration Steps
Start Microsoft Azure PowerShell with administrator credentials
1. Ensure that you are logged on to 20533B-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. Press the Windows key and on the Start screen, type Microsoft Azure PowerShell, right-click
Microsoft Azure PowerShell and then click Run as administrator.
3. In the User Account Control dialog box, click Yes.
Run Add-AzureAccount and log on to Azure
1. Type the following command and then press Enter:
Add-AzureAccount
2. Log on to Azure with the credentials associated with your Azure subscription.
Check your subscription using the Get-AzureSubscription cmdlets
1. Type Get-AzureSubscription and press Enter.
2. Show the subscription information.
Open existing NetworkConfig.XML
1. In File Explorer, navigate to D:\Demofiles\Mod02.
2. Double-click NetworkConfig.XML.
3. In the How do you want to open this type of file (.xml)? dialog box, click Notepad.
4. Show the students the contents of the file and point out that this is the same file from the slide in the
lesson.
5. Highlight the three subnets and the IP address ranges of each.
6. Do not close Notepad.

Import the network settings
1. In Microsoft Azure PowerShell, type the following command, and then press Enter:
Set-AzureVnetConfig D:\Demofiles\Mod02\NetworkConfig.XML
Show the settings for the new VNet in the Azure portal
1. When you see the success message, on the Windows Taskbar, click Internet Explorer.
2. In Internet Explorer, browse to the full Azure Management Portal at

https://manage.windowsazure.com, and sign in using the Microsoft account that is associated with
your Microsoft Azure subscription, in the Azure portal, click Networks.
3. Show the Main_Network VNet in the portal.
4. Click the right-arrow next to Main_Network.
5. Click CONFIGURE.
6. Point out the three subnets and their values.
In the NetworkConfig.XML file, change the subnet values to 192.168.30.x
1. Switch back to Notepad.
2. In the NetworkConfig.XML file, change all three instances of 192.168.0.x to 192.168.30.x (where x is
the last octet and is different in all cases. This does not change).
3. On the File menu, click Save.
Rerun the Set-AzureVnetConfig cmdlet
1. In Microsoft Azure PowerShell, type the following command and then press Enter:
Set-AzureVnetConfig D:\Demofiles\Mod02\NetworkConfig.XML
Refresh the screen in the portal and show that the IP subnets have now changed
1. In Internet Explorer, press F5 to refresh the browser page.
2. Point out that the IP address ranges are now have 192.168.30.x values.
Reset the environment
1. Close all open applications without saving any files.
Reset-Azure
Note: This script may remove Azure services in your subscription. It is 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 Microsoft Azure environment, ready for the next lab.
The script removes all storage, VMs, virtual networks and gateways, cloud services, and resource
groups.
Important: The script may 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.
Deploying a VM into a Virtual Network

Azure virtual networks can be used to contain VMs
and PaaS cloud services and ensure that those
resources are available to on-premises computers
as if they were installed on the local network. VMs
will be covered in much greater detail in Modules
3 and 4, however it is helpful to learn how deploy
a VM into a VNet at this point in order to
demonstrate that your VNet is configured
correctly.
In order to create a new VM in an existing VNet,

complete the following steps:
1. In the full portal, in the navigation on the left,

click VIRTUAL MACHINES.
2. In the toolbar at the bottom, click NEW and then click FROM GALLERY. Note that the QUICK
CREATE option does not allow you to specify a VNet.
3. Choose an operation system image and then click Next.
4. In the VIRTUAL MACHINE NAME text box, type a descriptive name for the server.
5. In the NEW USER NAME text box, type a name for the default administrator account.
6. In the NEW PASSWORD text box, type a secure password.
7. In the CONFIRM text box, retype the password and then click Next.
8. In the CLOUD SERVICE DNS NAME text box, ensure that a unique DNS name within the
cloudapp.net domain appears. If the name is unique a green tick is displayed. The default cloud
service name is taken from the VM name you specified on the previous page.
9. In the REGION/AFFINITY GROUP/VIRTUAL NETWORK drop-down list, select the virtual network
you want to add the new VM to.
10. If the VNet has more than one subnet, select the correct subnet in the VIRTUAL NETWORK
SUBNETS drop-down list.
11. Click Next and then click Finish.
Note: You can also use the preview portal or PowerShell to create new VMs in a VNet. You
will learn more about these techniques in Module 3.
Lab A: Creating Virtual Networks

Scenario
A. Datum has two large office buildings in different regions an HQ and a main branch office. In order to
serve these locations rapidly, you plan to have separate Azure virtual networks in the two regions that
match the office locations. Your Azure architects have provided a script that creates a virtual machine in
each virtual network. You have been asked to create the planning virtual networks and use the scripts to
populate them.
Objectives
After completing this lab, you will be able to:
Create virtual Azure virtual networks.
Lab Setup
Estimated Time: 60 minutes
Virtual Machine: 20533B-MIA-CL1

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 the Virtual Network

Scenario
A. Datum now wishes to implement virtual networks for the A. Datum HQ and branch resources. You are
also required to run a script to populate these resources with some test virtual machines.
The main tasks for this exercise are as follows:
1. Connect to Windows Azure with Windows Azure PowerShell
2. Create Virtual Networks in the Management Portal and in PowerShell

3. Populate the Virtual Network
Task 1: Connect to Windows Azure with Windows Azure PowerShell

1. Start Windows Azure PowerShell ISE with administrative credentials.
2. Use the Get-AzurePublishSettingsFile cmdlet to download the encoded management certificate for
your subscription.
3. Check your Azure Subscription settings using the Get-AzureSubscription command and record the
Current Storage Account Name value in D:\Labfiles\Lab02\Starter\ExampleCommands.ps1.
4. Run the Update-Help cmdlet. Leave the Windows Azure PowerShell ISE window open.
5. Record your Location 1 and Location 2 details in

D:\Labfiles\Lab02\Starter\ExampleCommands.ps1, and save the file.
Note: For Location 1 and Location 2 use two Azure regions close to your physical
location. Your instructor will provide this information.
Task 2: Create Virtual Networks in the Management Portal and in PowerShell

1. Log on to the full Microsoft Azure portal using your Microsoft identity that you created to register for
your Microsoft Azure Learning Pass.
2. In the Networks node, create a new virtual network with the following settings:
o NAME: ADATUM-HQ-VNET
o LOCATION: Your Location 1

o DNS and VPN Connectivity settings: add DNS server ADATUM-DNS, with IP address of 10.0.1.4
o Address space: 10.0.1.0/24
o Subnet name: Leave as default
o Subnet: Starting IP 10.0.1.0.
o CIDR: /25
3. Export the network configuration XML file and save this file onto your desktop.
4. Edit the file settings to copy the existing VIRTUALNETWORKSITE section, and then edit the new
VIRTUALNETWORKSITE section with the following information:
o NAME: ADATUM-BRANCH-VNET
o LOCATION: Your Location 2
o Address space: 10.0.2.0/24
o Subnet name: Leave as default

o Subnet: Starting IP 10.0.2.0.
o CIDR: /25
o DnsServersRef: Leave as ADATUM-DNS

5. Import the settings using the Set-AzureVNetConfig command and the NetworkConfig.XML file.
6. Check that both networks are displayed in the Microsoft Azure portal.
Task 3: Populate the Virtual Network

1. Switch to Windows PowerShell ISE.
2. At the Windows PowerShell ISE prompt, type the following command, and press Enter:
CD D:\Labfiles\Lab02\Starter
.\CreateVirtualMachines1.ps1
Important: The command starts with dot backslash.
4. When prompted for your primary Azure region, enter the number of your Location 1, and press
Enter.
5. The script may take 20 - 25 minutes to complete; when the script has completed, verify that the
following information is displayed:
o Name: AdatumWestSvr1
o IPAddress: 10.0.1.4
o InstanceStatus: ReadyRole
o PowerState: Started
6. Close the Windows PowerShell ISE. Important: do not run the second script in the same instance of
PowerShell.
7. On the taskbar, right-click Microsoft Azure PowerShell and click Run ISE as Administrator. Click
Yes when prompted.
8. In the Windows PowerShell ISE, in the command prompt pane, enter the following command and
press Enter:
CD D:\Labfiles\Lab02\Starter
9. In the Windows PowerShell ISE, in the command prompt pane, enter the following command and
press Enter:
.\CreateVirtualMachines2.ps1
Important: The command starts with dot backslash.
10. When prompted for your secondary Azure region, enter the number of your Location 2, and press
Enter.
11. The script may take 10 - 15 minutes to complete; when the script has completed, verify that the
following information is displayed:
o Name: AdatumEastSvr1
o IPAddress: 10.0.2.4
o InstanceStatus: ReadyRole
o PowerState: Started
12. Do not proceed to the next exercise until the script operation is complete.
Results: After completing this exercise, you will have created virtual networks for A. Datum HQ and
branch, and deployed a virtual machine to each network.
Question: What are the two methods you can use to create Azure virtual networks?
Lesson 3
Configuring Connections to Virtual Networks
In this third lesson, you will learn how to establish connectivity between two or more sites in Microsoft
Azure, as well as how to connect from your on-premises computers to Azure virtual networks. Here, you
will be covering subjects such as configuring site-to-site VPNs.
Lesson Objectives
After completing this lesson, you should be able to:
Describe the options for inter-site connectivity.
Configure a Point-to-Sit VPN.

Configure site-to-site VPNs.
Configure VNet-to-VNet VPNs.
List considerations that are important when configuring inter-site connectivity.
Inter-Site Connectivity Options

Remember that you can connect to VMs or PaaS
cloud services in a VNet through endpoints
without using VPN connections. However, an
endpoint specifies a particular port number and
uses a VIP so is restricted to a particular protocol
and purpose. For example, the RDP endpoint
cannot be used to send queries to a database.
By creating a VPN connection to a VNet, you allow

clients to connect as if the VNet resources were on
the local network. The cloud connection thus
becomes transparent to the user. All VPN
connections require a virtual gateway in the VNet,
which routes traffic to the on-premises computers. The available connections include:
Point-to-Site
A point-to-site VPN connects a single computer to a VNet 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. Remember that computers with a point-to-site VPN can use that connection from anywhere with
Internet access. For example, they could connect to the VNet from a caf with Wi-Fi.
Site-to-Site
A site-to-site VPN connects an on-premises TCP/IP network to a VNet through a VPN tunnel. In the on-
premises network, a VPN device routes traffic to the VNet. You can either use a compatible third-party
VPN device or use a Windows server with the Routing and Remote Access Service (RRAS) configured.
Azure provides a script that you can use to configure the VPN device.
Use site-to-site connection when you have a large number of client computers 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 VNet to another. The two VNets 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 organizations VNet, as long as the IP address spaces of the two VNets did not overlap.
When you configure a VNet-to-VNet connection, you must specify the IP address spaces in use for DIPs
on the opposite VNet so that the virtual gateway can route traffic to the correct location. This is referred
to, in the user interface, 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 VNet,
the first VNet is referred to as the local network.
Multisite
You can create a single VPN that connects multiple on-premises networks to a single VNet. This is known
as a multi-site VPN and is very similar to a site-to-site VPN. The main practical difference is that you must
configure a multi-site VPN by using a network configuration file. The portal does not support muti-site
VPNs at the time of writing.
For more information about configuring multi-site VPNs, see:
Configure a Multi-Site VPN

ExpressRoute
The ExpressRoute service can provide a private connection to an Azure VNet that does not cross the
Internet. This can improve security and achieve higher bandwidth, lower latency, and better reliability.
Microsoft works with network service providers to build these connections.
For more information about ExpressRoute, see:
ExpressRoute: An overview
Note: All of the configuration procedures described in this lesson use the full portal. You
can also use network configuration files to make all these changes and use the PowerShell Set-
AzureVNetConfig cmdlet to upload and apply your changes to Azure.
Configuring a Point-to-Site VPN

To set up a point-to-site VPN, you must configure
an IP address space, configure a virtual gateway,
create certificates, and install a client VPN
package.
Configuring an IP Address Space for

Clients
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 VNet or any other range used
for site-to-site or VNet-to-VNet connections. The
portal shows a warning if there is such an overlap:
1. In the full portal, in the navigation on the left, click NETWORKS.
2. In the list of virtual networks, click the name of the VNet 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.
Configuring a Virtual Gateway

Point-to-site connections require a virtual gateway in the VNet that routes traffic to client on-premises
computers. To create the virtual gateway:
1. From the CONFIGURATION page, click DASHBOARD.

2. In the toolbar at the bottom, click CREATE GATEWAY and then click YES.
The gateway creation process can take up to 30 minutes.
Creating Root and Client Certificates

Certificates are used to authenticate clients as they connect to the VPN and also to encrypt the
connection to ensure 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, take 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 and then press Enter:
makecert -sky exchange -r -n "CN=AdatumRootCertificate" -pe -a sha1 -len 2048 -ss My

"AdatumRootCertificate.cer"
3. In the full portal, in the navigation on the left, click NETWORKS.
4. In the list of virtual networks, click the VNet you want to configure and then click CERTIFICATES.
5. Click UPLOAD A ROOT CERTIFICATE.

6. Click BROWSE FOR FILE, locate and select the certificate you create, and then click Open.
7. Click Complete.
8. In the command prompt, type the following command, and then press Enter:
makecert.exe -n "CN=AdatumClientCertificate" -pe -sky exchange -m 96 -ss My -in

"AdatumRootCertificate" -is my -a sha1
Create and Install the VPN Client Configuration Package

To connect to the VPN, a client must use a client configuration package. This package must include the
client certificate you just created:
1. In the full 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 you just downloaded. If the User Control
dialog appears, 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 VNet.
1. Navigate to the list of VPN connections and locate the VPN connection you have created. The name
of the VPN connection will be the same as the name of the VNet in Azure.
2. Right-click the connection and then click Connect.
3. Click Continue, and then click Connect.
Configuring a Site-to-Site VPN
Note: To promote understanding, only

outline steps are included in the following
procedures. This is to provide an overview of the
process. In the lab, you will see the detailed
procedure for creating a VNet-to-VNet
connection, which is similar to creating a site-to-
site connection.
To configure a new virtual network and a site-to-

site VPN, follow these steps:
1. In the full portal, create a new VNet. On the

Virtual Network Details page, supply the following values:
o Name. Choose a descriptive, unique name.
o Location. Choose the Azure region closest to your user base.

2. On the DNS Servers and VPN Connectivity page, supply the following values:
o DNS Servers. Specify the DNS server name and IP address that VMs in the VNet will use for
name resolution.
o Configure Site-to-Site VPN. Selected.
o Local Network. Select or create a local network.

3. On the Site-to-Site Connectivity page, specify the properties of the on-premises network. You must
supply the following values:
o Name. Provide a descriptive name for the local network.
o VPN Device IP Address. This is 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.
4. On the Virtual Network Address Spaces page, fill in the IP address spaces and subnets you planned.
You must include a gateway subnet. The virtual gateway will be added to this subnet when you create
it.
5. When the VNet has been created, click the DASHBOARD tab.
6. In the toolbar at the bottom, click CREATE GATEWAY and then click Dynamic Routing.
7. 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 VNet and receives traffic from the virtual gateway. You can use Windows Server with RRAS
configured for this device or use a supported third-party device. To configure this device, you must
provide the following information:
The IP address of the virtual gateway in the VNet. This IP address will be displayed in the VNets
Dashboard page.
The shared key. This key is used to encrypt the VPN. You can obtain the shared key from the full
portal by clicking MANAGE KEY on the toolbar.
The VPN configuration script template. You can obtain the script from the full portal by clicking
Download VPN Device Script in the quick glance section.
For more information about compatible VPN devices, see:

Configuring a VNet-to-VNet VPN

You can use a VNet-to-VNet VPN to connect one
VNet to another. The connected VNets can be in
the same Azure region or different regions. They
can also be in the same subscription or different
subscriptions.
It is a long process to create a VNet-to-VNet VPN

and it can appear confusing. Bear in mind:
You must complete almost identical steps at

both ends of the VPN because the
configuration is symmetrical.
When you initially create a virtual gateway

you do not yet know the IP address of the virtual gateway at the opposite end of the connection.
Therefore use a dummy IP address.
Once both virtual gateways are created, you can return to configure the actually IP address of the
opposite gateway.
There is no on-premises network in a VNet-to-VNet connection. However, in the user interface, you
must configure a local network IP address range. For each VNet, the local network IP address range
refers to the DIP addresses in the opposite VNet.
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.
To create a VNet-to-VNet connection, complete these procedures:

1. Create two virtual networks. Do not enable point-to-site or site-to-site communication as part of the
initial configuration. Use IP address ranges that do not overlap.
2. Add each VNet as a local network to the opposite VNet. Use the dummy IP address.
3. Create dynamic routing virtual gateways in each VNet. Record the IP address of each virtual gateway.
4. Reconfigure each VNet with the real IP address of the virtual gateway you created in the opposite
VNet.
5. Connect the VPN virtual gateways.

Considerations for Inter-Site Connectivity

When planning and configuring your VPN
connections to and from VNets, bear the following
facts in mind:
Azure supports a maximum of 10 VPN tunnels

from each VNet. Each point-to-site VPN, site-
to-site VPN, or VNet-to-VNet VPN counts as
one of these VPN tunnels. Also a multi-site
VPN counts as one VPN tunnel for the
purposes of this restriction. A single point-to-
site VPN can support up to 254 connections
from client computers.
Address spaces must not overlap. Carefully

plan the address spaces you use in VNets and any connected on-premises networks.
VNet-to-VNet VPNs can connect VNets in the same or different Azure subscriptions. Similarly they
can connect VNets in the same or different Azure regions.
Redundant tunnels are not supported.
Cloud services cannot span VNets even when those VNets are connected with a VPN.
All VPN tunnels to a VNet share the available bandwidth on the Azure VPN gateway. This include
point-to-site VPNs.
VPN devices must support certain requirements. There is a list of these requirements at the following
location. You can also find a list of compatible third-party VPN devices on the same page.

Lab B: Connecting Virtual Networks

Scenario
You have been asked to implement connectivity to the two A. Datum virtual networks you created earlier.
You want to use a VNet-to-VNet VPN to connect the VNets. 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 will be able:
Connect Azure virtual networks using a VNet-to-VNet VPN.
Validate virtual network connectivity using Azure- and virtual machine-based tools.
Configure and test a point-to-site VPN.
Lab Setup
Estimated Time: 100 minutes
Virtual Machine: 20533B-MIA-CL1

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: Connecting the Virtual Networks

Scenario
A. Datum now wish to connect the A. Datum HQ and branch virtual networks by using a VPN.

1. Create a Virtual Network Gateway
2. Connect the Virtual Networks
Task 1: Create a Virtual Network Gateway

1. Use the full Azure portal to create two local networks in the Networks node, with the following
settings:
o NAME: ADATUM-HQ-LOCALNET
o VPN DEVICE IP ADDRESS: 1.1.1.1
o STARTING IP: 10.0.1.0
o CIDR: /24
o NAME: ADATUM-BRANCH-LOCALNET
o VPN DEVICE IP ADDRESS: 2.2.2.2
o STARTING IP: 10.0.2.0
o CIDR: /24
2. Use the full Azure portal to enable site-to-site VPNs by configuring ADATUM-HQ-VNET to connect
to ADATUM-BRANCH-LOCALNET, and add a gateway subnet, and configuring ADATUM-
BRANCH -VNET to connect to ADATUM-HQ-LOCALNET, and verify that a gateway subnet has
been created.
3. Use the full Azure portal to create dynamic routing gateways for ADATUM-HQ-VNET and
ADATUM-BRANCH-VNET.
4. Note that it will take 20-25 minutes for the gateways to be created; do not proceed until gateway
creation is complete.
Task 2: Connect the Virtual Networks

1. Use the full Azure portal to obtain the gateway IP address of the ADATUM-HQ-VNET virtual
network, and the ADATUM-BRANCH-VNET virtual network.
2. Use the full Azure portal to edit properties of ADATUM-HQ-LOCALNET to add the gateway IP
address of ADATUM-HQ-VNET.
3. Use the full Azure portal to edit properties of ADATUM-BRANCH-LOCALNET to add the gateway IP
address of ADATUM-BRANCH-VNET.
Set-AzureVNetGatewayKey -VNetName ADATUM-HQ-VNET -LocalNetworksiteName

ADATUM-BRANCH-LOCALNET -sharedKey abcdefgh1234
Set-AzureVNetGatewayKey -VNetName ADATUM-BRANCH-VNET -LocalNetworksiteName

ADATUM-HQ-LOCALNET -sharedKey abcdefgh1234
7. Use the full Azure portal to verify gateway configuration for ADATUM-HQ-VNET and ADATUM-
BRANCH-VNET; the Dashboard page now shows that a gateway has been created and connected for
the virtual network.
Get-AzureVNetConnection -VNetName ADATUM-HQ-VNET| ft LocalNetworkSiteName,
ConnectivityState
10. Verify that the ConnectivityState of ADATUM-BRANCH-LOCALNET shows as Connected.
Get-AzureVNetConnection -VNetName ADATUM-BRANCH-VNET| ft LocalNetworkSiteName,

ConnectivityState
12. Verify that the ConnectivityState of ADATUM-HQ-LOCALNET shows as Connected.
Results: After completing this exercise, you will have connected the A. Datum HQ and branch virtual
networks, and deployed dynamic routing gateways for each virtual network.
Exercise 2: Validating Virtual Network Connectivity

Scenario
A. Datum now wish to test the new Azure networking configuration, and validate the connectivity
between the A. Datum HQ and branch virtual networks. For test purposes, one of your virtual machines
has been configured (in the deployment script) as a DNS server, so that you can test name resolution
between linked virtual networks. You will RDP into these virtual machines.
1. Connect to A. Datum Virtual Machines
2. Testing TCP/IP Connectivity between Sites
3. Testing Name Resolution
Task 1: Connect to A. Datum Virtual Machines

1. Connect to AdatumWestSvr1 using D:\Labfiles\Lab02\Starter\AdatumWestSvr1.rdp.
2. If a Remote Desktop Connection warning message appears, select the Dont ask me again for
connections to this computer check box, and click Connect.
3. In the Windows Security dialog box, type the following credentials, and click OK:
o User name: Student
o Password: Pa$$w0rd123
4. If another Remote Desktop Message appears, select the Dont ask me again for connections to this
computer check box, and click Yes.
5. Minimize the AdatumWestSvr1 RDP session.
6. Connect to AdatumEastSvr1 using D:\Labfiles\Lab02\Starter\AdatumEastSvr1.rdp.
7. If a Remote Desktop Connection warning message appears, select the Dont ask me again for
connections to this computer check box, and click Connect.
8. In the Windows Security dialog box, type the following credentials, and click OK:
o User name: Student
o Password: Pa$$w0rd123
9. If another Remote Desktop Message appears, select the Dont ask me again for connections to this
computer check box, and click Yes.
10. Minimize the AdatumEastSvr1 RDP session.
Task 2: Testing TCP/IP Connectivity between Sites

1. Maximize the AdatumEastSvr1 session, and ensure that Windows Firewall is turned off for all profiles.
2. Minimize the AdatumEastSvr1 RDP session.
3. Maximize the AdatumWestSvr1 session, and ensure that Windows Firewall is turned off for all profiles.
4. In the AdatumWestSvr1 session, ping AdatumEastSvr1 (10.0.2.4) from AdatumWestSvr1 by IP address.
5. Maximize the AdatumEastSvr1 RDP session.
6. Ping AdatumWestSvr1 (10.0.1.4) from AdatumEastSvr1 by IP address.

Task 3: Testing Name Resolution

1. Use the PowerShell Test-NetConnection cmdlet to ping AdatumEastSvr1 from AdatumWestSvr1 by
fully qualified domain name.
2. Use the PowerShell Test-NetConnection cmdlet to ping AdatumWestSvr1 from AdatumEastSvr1 by

fully qualified domain name.
Results: After completing this exercise, you will have verified that virtual machines can communicate
between virtual networks.
Exercise 3: Configuring a Point-to-Site VPN

Scenario
A. Datum now wish to implement secure communications from on-premises resources to Azure, and wish
to start by configuring and testing a point-to-site VPN connection to one of the gateways you created in
Exercise 3.
Only complete this lab if you have sufficient time remaining.
Important: Even if you do not complete this exercise, you must ensure 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. Configuring a VPN from Client to HQ Virtual Network
2. Connecting to the HQ Virtual Network

3. Reset the Environment
Task 1: Configuring a VPN from Client to HQ Virtual Network

Enable point-to-site connectivity for the ADATUM-HQ-VNET virtual network.
1. Use the Windows key, and then type Command.

2. Right-click Command Prompt, and then click Run as administrator.
3. In the User Account Control dialog box, click Yes.
4. At the Command Prompt, type the following command, and press Enter:
CD C:\Program Files (x86)\Windows Kits\8.1\bin\x64
makecert -sk exchange -r -n "CN=AdatumRootCertificate" -pe -a sha1 -len 2048 -ss My

"AdatumRootCertificate.cer"
6. On the ADATUM-HQ-VNET CERTIFICATES page in the Azure Management Portal, upload the self-
signed root certificate.
7. Switch to the Command Prompt.
makecert.exe -n "CN=AdatumClientCertificate" -pe -sk exchange -m 96 -ss My -in

"AdatumRootCertificate" -is my -a sha1
9. Verify client certificate installation in Internet Explorer.
Task 2: Connecting to the HQ Virtual Network

1. Configure VPN client by downloading the 64-bit Client VPN Package, and installing it on the local
client.
2. From the local client, connect to the VPN, and verify VPN connection using ipconfig/all.
3. Verify the VPN connection by browsing files on \\adatumwestsvr1.adatum.msft\c$.
4. Disconnect the VPN connection.
Task 3: Reset the Environment

1. Close all open applications without saving any files.
Reset-Azure
Note: This script may remove Azure services in your subscription. It is 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 Microsoft Azure environment, ready for the next lab.
The script removes all storage, VMs, virtual networks and gateways, cloud services, and resource
groups.
Important: The script may 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.
Results: After completing this exercise, you will have configured and tested a point-to-site VPN
connection.

Lab Azure

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Lab Azure

Загружено:

Авторское право:

Доступные форматы

MCT USE ONLY.

STUDENT USE PROHIBITED

Describe the overall functioning of virtual networking in Microsoft Azure.

Plan a VPN connection from one Azure virtual network to another.

Design IP address space and subnet allocation to manage host numbers.

Plan for effective name resolution in Microsoft Azure virtual networks.

Demonstration: Preparing the Environment

Prepare the Azure Environment

2. Type the following command, and then press Enter:

4. Confirm your selection, and then press Enter.

6. When the script is complete, close PowerShell and Internet Explorer.

Virtual Networks as a Component of Azure

Overview of Virtual Networks

You can create VMs in Azure without using VNets.

Virtual Network Features

VNets for Cloud Services and Virtual

Setting a Static Internal IP Address

#Assign the IP address

Adding a Reserved IP for a New VM

New-AzureVMConfig -Name "WebFrontEndVM1" -InstanceSize Small -ImageName $imageName | Add-

Assigning an Instance-Level PIP to a VM

Create a VM with Multiple NICs

Azure Load Balancer and Internal Load Balancer

Internal Load Balancing

Instance-Level Public IP Addresses

Connecting to Virtual Networks

Cloud-Only Virtual Networks

You will learn how to configure a Point-to-Site VPN in Lesson 2.

About VPN Devices for Virtual Network

ExpressRoute Technical Overview

Comparing Site-to-Site and VNet-to-

An IP addressing scheme in the VNet.

A gateway in the local subnet.

A virtual gateway in the VNet.

An IP addressing scheme in the West US VNet.

An IP addressing scheme in the North Europe VNet.

A virtual gateway in the North Europe VNet.

Note: You will configure a VNet-to-VNet VPN connection in the lab.

Designing IP Address Space and Subnet Allocation in Azure

Private Address Spaces

Use Static Internal IP Addresses

Planning for Name Resolution in Azure Virtual Networks

Azure provides a name resolution service that

Consider the following situations:

The server must support Dynamic DNS (DDNS) registration.

The server must have DNS recursion enabled.

The server must be accessible on TCP/UDP port 53 from all clients.

Navigate the schema of a network configuration file.

Create and modify a virtual network by using a network configuration file.

Creating Virtual Networks using the Management Portal

Note: At the time of writing, the preview

To create a cloud-only virtual network in the full

1. In the navigation menu on the left, click Networks.

6. Click the Next arrow.

Network Configuration Files

The name and location of the VNet.

DNS servers for the VNet.

IP private addresses spaces for DIPs in the

Subnets within the private address spaces.

The IP address of the virtual gateway that

Sample Network Configuration File

Exporting and Importing Network Configuration Files

The following PowerShell commands export a