Table of Contents Overview About virtual machines Disks and VHDs Virtual Networks FAQ Compare VMs, websites, and cloud services Containers Get started Create a VM using the portal Log on to a VM Install Azure PowerShell Install Azure CLI How to Use Storage Attach a data disk Detach a data disk Use D: as a data disk Network How to set up endpoints Connect VMs with a VNet or Cloud Service Connect Classic VNets to Resource Manager VNets Create a load balancer Manage NSGs using Azure PowerShell Deploy Create a custom VM Create and configure a VM using Azure PowerShell Capture a Windows VM Create and upload a VHD using PowerShell Automate Azure VM deployment with Chef
Create and Manage VMs in Visual Studio Create a VM for a web app with Visual Studio Run a compute-intensive task in Java Django Hello World web application Configure Reset a password or the Remote Desktop service Install and configure Symantec Endpoint Protection Install and configure Trend Micro Deep Security as a Service Configure an availability set Resize a Windows VM created in the classic deployment model Manage Migrate from Classic to Resource Manager Manage your VMs using Azure PowerShell About the VM agent and extensions Manage VM extensions Custom Script extension for VMs Injecting custom data into an Azure VM Plan About images Sizes for VMs Planned maintenance for Azure VMs Azure infrastructure services implementation guidelines Manage workloads High-performance Computing (HPC) MongoDB MySQL Oracle SAP SQL Server Tomcat Troubleshoot Remote Desktop connections
Access to an application Classic deployment issues with creating a new VM Classic deployment issues with restarting or resizing an existing VM Reset RDP password Reference PowerShell Azure CLI Java .NET Author Resource Manager templates Community templates Compute REST Network REST Storage REST Resources Pricing Regional availability Stack Overflow Videos
1 min to read • Edit O nline
About disks and VHDs for Azure Windows VMs 5/26/2017 • 8 min to read • Edit Online
Just like any other computer, virtual machines in Azure use disks as a place to store an operating system, applications, and data. All Azure virtual machines have at least two disks – a Windows operating system disk and a temporary disk. The operating system disk is created from an image, and both the operating system disk and the image are virtual hard disks (VHDs) stored in an Azure storage account. Virtual machines also can have one or more data disks, that are also stored as VHDs. In this article, we will talk about the different uses for the disks, and then discuss the different types of disks you can create and use. This article is also available for Linux virtual machines. NOTE Azure has two different deployment models for creating and working with resources: Resource Manager and classic. This article covers using both models, but Microsoft recommends that most new deployments use the Resource Manager model.
Disks used by VMs Let's take a look at how the disks are used by the VMs. Operating system disk Every virtual machine has one attached operating system disk. It's registered as a SATA drive and labeled as the C: drive by default. This disk has a maximum capacity of 1023 gigabytes (GB). Temporary disk Each VM contains a temporary disk. The temporary disk provides short-term storage for applications and processes and is intended to only store data such as page or swap files. Data on the temporary disk may be lost during a maintenance event or when you redeploy a VM. During a standard reboot of the VM, the data on the temporary drive should persist. The temporary disk is labeled as the D: drive by default and it used for storing pagefile.sys. To remap this disk to a different drive letter, see Change the drive letter of the Windows temporary disk. The size of the temporary disk varies, based on the size of the virtual machine. For more information, see Sizes for Windows virtual machines. For more information on how Azure uses the temporary disk, see Understanding the temporary drive on Microsoft Azure Virtual Machines Data disk A data disk is a VHD that's attached to a virtual machine to store application data, or other data you need to keep. Data disks are registered as SCSI drives and are labeled with a letter that you choose. Each data disk has a maximum capacity of 1023 GB. The size of the virtual machine determines how many data disks you can attach to it and the type of storage you can use to host the disks. NOTE For more information about virtual machines capacities, see Sizes for Windows virtual machines.
Azure creates an operating system disk when you create a virtual machine from an image. If you use an image that includes data disks, Azure also creates the data disks when it creates the virtual machine. Otherwise, you add data
disks after you create the virtual machine. You can add data disks to a virtual machine at any time, by attaching the disk to the virtual machine. You can use a VHD that you've uploaded or copied to your storage account, or one that Azure creates for you. Attaching a data disk associates the VHD file with the VM by placing a 'lease' on the VHD so it can't be deleted from storage while it's still attached.
About VHDs The VHDs used in Azure are .vhd files stored as page blobs in a standard or premium storage account in Azure. For details about page blobs, see Understanding block blobs and page blobs. For details about premium storage, see High-performance premium storage and Azure VMs. Azure supports the fixed disk VHD format. The fixed format lays the logical disk out linearly within the file, so that disk offset X is stored at blob offset X. A small footer at the end of the blob describes the properties of the VHD. Often, the fixed format wastes space because most disks have large unused ranges in them. However, Azure stores .vhd files in a sparse format, so you receive the benefits of both the fixed and dynamic disks at the same time. For more details, see Getting started with virtual hard disks. All .vhd files in Azure that you want to use as a source to create disks or images are read-only. When you create a disk or image, Azure makes copies of the .vhd files. These copies can be read-only or read-and-write, depending on how you use the VHD. When you create a virtual machine from an image, Azure creates a disk for the virtual machine that is a copy of the source .vhd file. To protect against accidental deletion, Azure places a lease on any source .vhd file that’s used to create an image, an operating system disk, or a data disk. Before you can delete a source .vhd file, you’ll need to remove the lease by deleting the disk or image. To delete a .vhd file that is being used by a virtual machine as an operating system disk, you can delete the virtual machine, the operating system disk, and the source .vhd file all at once by deleting the virtual machine and deleting all associated disks. However, deleting a .vhd file that’s a source for a data disk requires several steps in a set order. First you detach the disk from the virtual machine, then delete the disk, and then delete the .vhd file. WARNING If you delete a source .vhd file from storage, or delete your storage account, Microsoft can't recover that data for you.
Types of disks There are two performance tiers for storage that you can choose from when creating your disks -- Standard Storage and Premium Storage. Also, there are two types of disks -- unmanaged and managed -- and they can reside in either performance tier. Standard storage Standard Storage is backed by HDDs, and delivers cost-effective storage while still being performant. Standard storage can be replicated locally in one datacenter, or be geo-redundant with primary and secondary data centers. For more information about storage replication, please see Azure Storage replication. For more information about using Standard Storage with VM disks, please see Standard Storage and Disks. Premium storage Premium Storage is backed by SSDs, and delivers high-performance, low-latency disk support for VMs running I/O-intensive workloads. You can use Premium Storage with DS, DSv2, GS, or FS series Azure VMs. For more information, please see Premium Storage.
Unmanaged disks Unmanaged disks are the traditional type of disks that have been used by VMs. With these, you create your own storage account and specify that storage account when you create the disk. You have to make sure you don't put too many disks in the same storage account, because you could exceed the scalability targets of the storage account (20,000 IOPS, for example), resulting in the VMs being throttled. With unmanaged disks, you have to figure out how to maximize the use of one or more storage accounts to get the best performance out of your VMs. Managed disks Managed Disks handles the storage account creation/management in the background for you, and ensures that you do not have to worry about the scalability limits of the storage account. You simply specify the disk size and the performance tier (Standard/Premium), and Azure creates and manages the disk for you. Even as you add disks or scale the VM up and down, you don't have to worry about the storage being used. You can also manage your custom images in one storage account per Azure region, and use them to create hundreds of VMs in the same subscription. For more information about Managed Disks, please see the Managed Disks Overview. We recommend that you use Azure Managed Disks for new VMs, and that you convert your previous unmanaged disks to managed disks, to take advantage of the many features available in Managed Disks. Disk comparison The following table provides a comparison of Premium vs Standard for both unmanaged and managed disks to help you decide what to use. AZURE PREMIUM DISK
AZURE STANDARD DISK
Disk Type
Solid State Drives (SSD)
Hard Disk Drives (HDD)
Overview
SSD-based high-performance, lowlatency disk support for VMs running IO-intensive workloads or hosting mission critical production environment
HDD-based cost effective disk support for Dev/Test VM scenarios
Scenario
Production and performance sensitive workloads
Dev/Test, non-critical, Infrequent access
Disk Size
P10: 128 GB P20: 512 GB P30: 1024 GB
Unmanaged Disks: 1 GB – 1 TB
Max Throughput per Disk
200 MB/s
60 MB/s
Max IOPS per Disk
5000 IOPS
500 IOPS
Managed Disks: S4: 32 GB S6: 64 GB S10: 128 GB S20: 512 GB S30: 1024 GB
One last recommendation: Use TRIM with unmanaged standard disks If you use unmanaged standard disks (HDD), you should enable TRIM. TRIM discards unused blocks on the disk so you are only billed for storage that you are actually using. This can save on costs if you create large files and then delete them. You can run this command to check the TRIM setting. Open a command prompt on your Windows VM and type:
fsutil behavior query DisableDeleteNotify
If the command returns 0, TRIM is enabled correctly. If it returns 1, run the following command to enable TRIM: fsutil behavior set DisableDeleteNotify 0
NOTE Note: Trim support starts with Windows Server 2012 / Windows 8 and above, see see New API allows apps to send "TRIM and Unmap" hints to storage media.
Next steps Attach a disk to add additional storage for your VM. Change the drive letter of the Windows temporary disk so your application can use the D: drive for data.
Azure Virtual Network 5/1/2017 • 6 min to read • Edit Online
The Azure Virtual Network service enables you to securely connect Azure resources to each other with virtual networks (VNets). A VNet is a representation of your own network in the cloud. A VNet is a logical isolation of the Azure cloud dedicated to your subscription. You can also connect VNets to your on-premises network. The following picture shows some of the capabilities of the Azure Virtual Network service:
To learn more about the following Azure Virtual Network capabilities, click the capability: Isolation: VNets are isolated from one another. You can create separate VNets for development, testing, and production that use the same CIDR address blocks. Conversely, you can create multiple VNets that use different CIDR address blocks and connect networks together. You can segment a VNet into multiple subnets. Azure provides internal name resolution for VMs and Cloud Services role instances connected to a VNet. You can optionally configure a VNet to use your own DNS servers, instead of using Azure internal name resolution. Internet connectivity: All Azure Virtual Machines (VM) and Cloud Services role instances connected to a VNet have access to the Internet, by default. You can also enable inbound access to specific resources, as needed. Azure resource connectivity: Azure resources such as Cloud Services and VMs can be connected to the same VNet. The resources can connect to each other using private IP addresses, even if they are in different subnets. Azure provides default routing between subnets, VNets, and on-premises networks, so you don't have to configure and manage routes. VNet connectivity: VNets can be connected to each other, enabling resources connected to any VNet to communicate with any resource on any other VNet. On-premises connectivity: VNets can be connected to on-premises networks through private network connections between your network and Azure, or through a site-to-site VPN connection over the Internet. Traffic filtering: VM and Cloud Services role instances network traffic can be filtered inbound and outbound by source IP address and port, destination IP address and port, and protocol. Routing: You can optionally override Azure's default routing by configuring your own routes, or using BGP routes through a network gateway.
Network isolation and segmentation You can implement multiple VNets within each Azure subscription and Azure region. Each VNet is isolated from other VNets. For each VNet you can: Specify a custom private IP address space using public and private (RFC 1918) addresses. Azure assigns resources connected to the VNet a private IP address from the address space you assign. Segment the VNet into one or more subnets and allocate a portion of the VNet address space to each subnet.
Use Azure-provided name resolution or specify your own DNS server for use by resources connected to a VNet. To learn more about name resolution in VNets, read the Name resolution for VMs and Cloud Services article.
Connect to the Internet All resources connected to a VNet have outbound connectivity to the Internet by default. The private IP address of the resource is source network address translated (SNAT) to a public IP address by the Azure infrastructure. To learn more about outbound Internet connectivity, read the Understanding outbound connections in Azure article. You can change the default connectivity by implementing custom routing and traffic filtering. To communicate inbound to Azure resources from the Internet, or to communicate outbound to the Internet without SNAT, a resource must be assigned a public IP address. To learn more about public IP addresses, read the Public IP addresses article.
Connect Azure resources You can connect several Azure resources to a VNet, such as Virtual Machines (VM), Cloud Services, App Service Environments, and Virtual Machine Scale Sets. VMs connect to a subnet within a VNet through a network interface (NIC). To learn more about NICs, read the Network interfaces article.
Connect virtual networks You can connect VNets to each other, enabling resources connected to either VNet to communicate with each other across VNets. You can use either or both of the following options to connect VNets to each other: Peering: Enables resources connected to different Azure VNets within the same Azure location to communicate with each other. The bandwidth and latency across the VNets is the same as if the resources were connected to the same VNet. To learn more about peering, read the Virtual network peering article. VNet-to-VNet connection: Enables resources connected to different Azure VNet within the same, or different Azure locations. Unlike peering, bandwidth is limited between VNets because traffic must flow through an Azure VPN Gateway. To learn more about connecting VNets with a VNet-to-VNet connection, read the Configure a VNet-to-VNet connection article.
Connect to an on-premises network You can connect your on-premises network to a VNet using any combination of the following options: Point-to-site virtual private network (VPN): Established between a single PC connected to your network and the VNet. This connection type is great if you're just getting started with Azure, or for developers, because it requires little or no changes to your existing network. The connection uses the SSTP protocol to provide encrypted communication over the Internet between the PC and the VNet. The latency for a point-to-site VPN is unpredictable, since the traffic traverses the Internet. Site-to-site VPN: Established between your VPN device and an Azure VPN Gateway. This connection type enables any on-premises resource you authorize to access a VNet. The connection is an IPSec/IKE VPN that provides encrypted communication over the Internet between your on-premises device and the Azure VPN gateway. The latency for a site-to-site connection is unpredictable, since the traffic traverses the Internet. Azure ExpressRoute: Established between your network and Azure, through an ExpressRoute partner. This connection is private. Traffic does not traverse the Internet. The latency for an ExpressRoute connection is predictable, since traffic doesn't traverse the Internet. To learn more about all the previous connection options, read the Connection topology diagrams article.
Filter network traffic
You can filter network traffic between subnets using either or both of the following options: Network security groups (NSG): Each NSG can contain multiple inbound and outbound security rules that enable you to filter traffic by source and destination IP address, port, and protocol. You can apply an NSG to each NIC in a VM. You can also apply an NSG to the subnet a NIC, or other Azure resource, is connected to. To learn more about NSGs, read the Network security groups article. Network virtual appliances (NVA): An NVA is a VM running software that performs a network function, such as a firewall. View a list of available NVAs in the Azure Marketplace. NVAs are also available that provide WAN optimization and other network traffic functions. NVAs are typically used with user-defined or BGP routes. You can also use an NVA to filter traffic between VNets.
Route network traffic Azure creates route tables that enable resources connected to any subnet in any VNet to communicate with each other, by default. You can implement either or both of the following options to override the default routes Azure creates: User-defined routes: You can create custom route tables with routes that control where traffic is routed to for each subnet. To learn more about user-defined routes, read the User-defined routes article. BGP routes: If you connect your VNet to your on-premises network using an Azure VPN Gateway or ExpressRoute connection, you can propagate BGP routes to your VNets.
Pricing There is no charge for virtual networks, subnets, route tables, or network security groups. Outbound Internet bandwidth usage, public IP addresses, virtual network peering, VPN Gateways, and ExpressRoute each have their own pricing structures. View the Virtual network, VPN Gateway, and ExpressRoute pricing pages for more information.
FAQ To review frequently asked questions about Virtual Network, see the Virtual Network FAQ article.
Next steps Create your first VNet, and connect a few VMs to it, by completing the steps in the Create your first virtual network article. Create a point-to-site connection to a VNet by completing the steps in the Configure a point-to-site connection article.
Frequently asked question about Azure Windows virtual machines created with the classic deployment model 3/30/2017 • 11 min to read • Edit Online
IMPORTANT Azure has two different deployment models for creating and working with resources: Resource Manager and Classic. This article covers using the Classic deployment model. Microsoft recommends that most new deployments use the Resource Manager model. For the FAQ when using the Resource Manager model, see here.
This article addresses some common questions users ask about Azure virtual machines created with the classic deployment model.
Can I migrate my VM created in the classic deployment model to the new Resource Manager model? Yes. For instructions on how to migrate, see: Migrate from classic to Azure Resource Manager using Azure PowerShell. Migrate from classic to Azure Resource Manager using Azure CLI.
What can I run on an Azure VM? All subscribers can run server software on an Azure virtual machine. You can run recent versions of Windows Server, as well as a variety of Linux distributions. For support details, see: • For Windows VMs -- Microsoft server software support for Azure Virtual Machines • For Linux VMs -- Linux on Azure-Endorsed Distributions For Windows client images, certain versions of Windows 7 and Windows 8.1 are available to MSDN Azure benefit subscribers and MSDN Dev and Test Pay-As-You-Go subscribers, for development and test tasks. For details, including instructions and limitations, see Windows Client images for MSDN subscribers.
Why are affinity groups being deprecated? Affinity groups are a legacy concept for a geographical grouping of a customer’s cloud service deployments and storage accounts within Azure. They were originally provided to improve VM-to-VM network performance in the early Azure network designs. They also supported the initial release of virtual networks (VNets), which were limited to a small set of hardware in a region. The current Azure network within a region is designed so that affinity groups are no longer required. Virtual networks are also at a regional scope, so an affinity group is no longer required when you use a virtual network. Due to these improvements, we no longer recommend that customers use affinity groups because they can be limiting in some scenarios. Using affinity groups will unnecessarily associate your VMs to specific hardware that limits the choice of VM sizes that are available to you. It might also lead to capacity-related errors when you attempt to add new VMs if the specific hardware associated with the affinity group is near capacity.
Affinity group features are already deprecated in the Azure Resource Manager deployment model and in the Azure portal. For the classic Azure portal, we're deprecating support for creating affinity groups and creating storage resources that are pinned to an affinity group. You don't need to modify existing cloud services that are using an affinity group. However, you should not use affinity groups for new cloud services unless an Azure support professional recommends them.
How much storage can I use with a virtual machine? Each data disk can be up to 1 TB. The number of data disks you can use depends on the size of the virtual machine. For details, see Sizes for Virtual Machines. An Azure storage account provides storage for the operating system disk and any data disks. Each disk is a .vhd file stored as a page blob. For pricing details, see Storage Pricing Details.
Which virtual hard disk types can I use? Azure only supports fixed, VHD-format virtual hard disks. If you have a VHDX that you want to use in Azure, you need to first convert it by using Hyper-V Manager or the convert-VHD cmdlet. After you do that, use AddAzureVHD cmdlet (in Service Management mode) to upload the VHD to a storage account in Azure so you can use it with virtual machines. For Linux instructions, see Creating and Uploading a Virtual Hard Disk that Contains the Linux Operating System. For Windows instructions, see Create and upload a Windows Server VHD to Azure.
Are these virtual machines the same as Hyper-V virtual machines? In many ways they’re similar to “Generation 1” Hyper-V VMs, but they’re not exactly the same. Both types provide virtualized hardware, and the VHD-format virtual hard disks are compatible. This means you can move them between Hyper-V and Azure. Three key differences that sometimes surprise Hyper-V users are: Azure doesn’t provide console access to a virtual machine. There is no way to access a VM until it is done booting. Azure VMs in most sizes have only 1 virtual network adapter, which means that they also can have only 1 external IP address. (The A8 and A9 sizes use a second network adapter for application communication between instances in limited scenarios.) Azure VMs don't support Generation 2 Hyper-V VM features. For details about these features, see Virtual Machine Specifications for Hyper-V and Generation 2 Virtual Machine Overview.
Can these virtual machines use my existing, on-premises networking infrastructure? For virtual machines created in the classic deployment model, you can use Azure Virtual Network to extend your existing infrastructure. The approach is like setting up a branch office. You can provision and manage virtual private networks (VPNs) in Azure as well as securely connect them to on-premises IT infrastructure. For details, see Virtual Network Overview. You’ll need to specify the network that you want the virtual machine to belong to when you create the virtual machine. You can’t join an existing virtual machine to a virtual network. However, you can work around this by detaching the virtual hard disk (VHD) from the existing virtual machine, and then use it to create a new virtual machine with the networking configuration you want.
How can I access my virtual machine?
You need to establish a remote connection to log on to the virtual machine by using Remote Desktop Connection for a Windows VM or a Secure Shell (SSH) for a Linux VM. For instructions, see: How to Log on to a Virtual Machine Running Windows Server. A maximum of 2 concurrent connections are supported, unless the server is configured as a Remote Desktop Services session host. How to Log on to a Virtual Machine Running Linux. By default, SSH allows a maximum of 10 concurrent connections. You can increase this number by editing the configuration file. If you’re having problems with Remote Desktop or SSH, install and use the VMAccess extension to help fix the problem. For Windows VMs, additional options include: In the Azure classic portal, find the VM, then click Reset Remote Access from the Command bar. Review Troubleshoot Remote Desktop connections to a Windows-based Azure Virtual Machine. Use Windows PowerShell Remoting to connect to the VM, or create additional endpoints for other resources to connect to the VM. For details, see How to Set Up Endpoints to a Virtual Machine. If you’re familiar with Hyper-V, you might be looking for a tool similar to VMConnect. Azure doesn’t offer a similar tool because console access to a virtual machine isn’t supported.
Can I use the temporary disk (the D: drive for Windows or /dev/sdb1 for Linux) to store data? You shouldn’t use the temporary disk (the D: drive by default for Windows or /dev/sdb1 for Linux) to store data. They are only temporary storage, so you would risk losing data that can’t be recovered. This can occur when the virtual machine moves to a different host. Resizing a virtual machine, updating the host, or a hardware failure on the host are some of the reasons a virtual machine might move.
How can I change the drive letter of the temporary disk? On a Windows virtual machine, you can change the drive letter by moving the page file and reassigning drive letters, but you’ll need to make sure you do the steps in a specific order. For instructions, see Change the drive letter of the Windows temporary disk.
How can I upgrade the guest operating system? The term upgrade generally means moving to a more recent release of your operating system, while staying on the same hardware. For Azure VMs, the process for moving to a more recent release differs for Linux and Windows: For Linux VMs, use the package management tools and procedures appropriate for the distribution. For a Windows virtual machine, you need to migrate the server using something like the Windows Server Migration Tools. Don’t attempt to upgrade the guest OS while it resides on Azure. It isn’t supported because of the risk of losing access to the virtual machine. If problems occur during the upgrade, you could lose the ability to start a Remote Desktop session and wouldn’t be able to troubleshoot the problems. For general details about the tools and processes for migrating a Windows Server, see Migrate Roles and Features to Windows Server.
What's the default user name and password on the virtual machine? The images provided by Azure don’t have a pre-configured user name and password. When you create virtual machine using one of those images, you’ll need to provide a user name and password, which you’ll use to log on to the virtual machine.
If you’ve forgotten the user name or password and you’ve installed the VM Agent, you can install and use the VMAccess extension to fix the problem. Additional details: For the Linux images, if you use the Azure classic portal, ‘azureuser’ is given as a default user name, but you can change this by using ‘From Gallery’ instead of ‘Quick Create’ as the way to create the virtual machine. Using ‘From Gallery’ also lets you decide whether to use a password, an SSH key, or both to log you in. The user account is a non-privileged user that has ‘sudo’ access to run privileged commands. The ‘root’ account is disabled. For Windows images, you’ll need to provide a user name and password when you create the VM. The account is added to the Administrators group.
Can Azure run anti-virus on my virtual machines? Azure offers several options for anti-virus solutions, but it’s up to you to manage it. For example, you might need a separate subscription for antimalware software, and you’ll need to decide when to run scans and install updates. You can add anti-virus support with a VM extension for Microsoft Antimalware, Symantec Endpoint Protection, or TrendMicro Deep Security Agent when you create a Windows virtual machine, or at a later point. The Symantec and TrendMicro extensions let you use a free limited-time trial subscription or an existing enterprise subscription. Microsoft Antimalware is free of charge. For details, see: How to install and configure Symantec Endpoint Protection on an Azure VM How to install and configure Trend Micro Deep Security as a Service on an Azure VM Deploying Antimalware Solutions on Azure Virtual Machines
What are my options for backup and recovery? Azure Backup is available as a preview in certain regions. For details, see Back up Azure virtual machines. Other solutions are available from certified partners. To find out what’s currently available, search the Azure Marketplace. An additional option is to use the snapshot capabilities of blob storage. To do this, you’ll need to shut down the VM before any operation that relies on a blob snapshot. This saves pending data writes and puts the file system in a consistent state.
How does Azure charge for my VM? Azure charges an hourly price based on the VM’s size and operating system. For partial hours, Azure charges only for the minutes of use. If you create the VM with a VM image containing certain pre-installed software, additional hourly software charges may apply. Azure charges separately for storage for the VM’s operating system and data disks. Temporary disk storage is free. You are charged when the VM status is Running or Stopped, but you are not charged when the VM status is Stopped (De-allocated). To put a VM in the Stopped (De-allocated) state, do one of the following: Shut down or delete the VM from the Azure classic portal. Use the Stop-AzureVM cmdlet, available in the Azure PowerShell module. Use the Shutdown Role operation in the Service Management REST API and specify StoppedDeallocated for the PostShutdownAction element. For more details, see Virtual Machines Pricing.
Will Azure reboot my VM for maintenance? Azure sometimes restarts your VM as part of regular, planned maintenance updates in the Azure datacenters.
Unplanned maintenance events can occur when Azure detects a serious hardware problem that affects your VM. For unplanned events, Azure automatically migrates the VM to a healthy host and restarts the VM. For any standalone VM (meaning the VM isn’t part of an availability set), Azure notifies the subscription’s Service Administrator by email at least one week before planned maintenance because the VMs could be restarted during the update. Applications running on the VMs could experience downtime. You also can use the Azure classic portal or Azure PowerShell to view the reboot logs when the reboot occurred due to planned maintenance. For details, see Viewing VM Reboot Logs. To provide redundancy, put two or more similarly configured VMs in the same availability set. This helps ensure at least one VM is available during planned or unplanned maintenance. Azure guarantees certain levels of VM availability for this configuration. For details, see Manage the availability of virtual machines.
Additional resources About Azure Virtual Machines Different Ways to Create a Linux Virtual Machine Different Ways to Create a Windows Virtual Machine
Azure App Service, Virtual Machines, Service Fabric, and Cloud Services comparison 6/2/2017 • 12 min to read • Edit Online
Overview Azure offers several ways to host web sites: Azure App Service, Virtual Machines, Service Fabric, and Cloud Services. This article helps you understand the options and make the right choice for your web application. Azure App Service is the best choice for most web apps. Deployment and management are integrated into the platform, sites can scale quickly to handle high traffic loads, and the built-in load balancing and traffic manager provide high availability. You can move existing sites to Azure App Service easily with an online migration tool, use an open-source app from the Web Application Gallery, or create a new site using the framework and tools of your choice. The WebJobs feature makes it easy to add background job processing to your App Service web app. Service Fabric is a good choice if you’re creating a new app or re-writing an existing app to use a microservice architecture. Apps, which run on a shared pool of machines, can start small and grow to massive scale with hundreds or thousands of machines as needed. Stateful services make it easy to consistently and reliably store app state, and Service Fabric automatically manages service partitioning, scaling, and availability for you. Service Fabric also supports WebAPI with Open Web Interface for .NET (OWIN) and ASP.NET Core. Compared to App Service, Service Fabric also provides more control over, or direct access to, the underlying infrastructure. You can remote into your servers or configure server startup tasks. Cloud Services is similar to Service Fabric in degree of control versus ease of use, but it’s now a legacy service and Service Fabric is recommended for new development. If you have an existing application that would require substantial modifications to run in App Service or Service Fabric, you could choose Virtual Machines in order to simplify migrating to the cloud. However, correctly configuring, securing, and maintaining VMs requires much more time and IT expertise compared to Azure App Service and Service Fabric. If you are considering Azure Virtual Machines, make sure you take into account the ongoing maintenance effort required to patch, update, and manage your VM environment. Azure Virtual Machines is Infrastructure-as-a-Service (IaaS), while App Service and Service Fabric are Platform-as-a-Service (Paas).
Feature Comparison The following table compares the capabilities of App Service, Cloud Services, Virtual Machines, and Service Fabric to help you make the best choice. For current information about the SLA for each option, see Azure Service Level Agreements. FEATURE
APP SERVICE (WEB APPS)
CLOUD SERVICES (WEB ROLES)
VIRTUAL MACHINES
SERVICE FABRIC
NOTES
FEATURE
APP SERVICE (WEB APPS)
CLOUD SERVICES (WEB ROLES)
VIRTUAL MACHINES
SERVICE FABRIC
NOTES
Deploying an application or an application update to a Cloud Service, or creating a VM, takes several minutes at least; deploying an application to a web app takes seconds.
Near-instant deployment
X
X
Scale up to larger machines without redeploy
X
X
Web server instances share content and configuration, which means you don't have to redeploy or reconfigure as you scale.
X
X
Multiple deployment environments (production and staging)
X
X
Automatic OS update management
X
X
Seamless platform switching (easily move between 32 bit and 64 bit)
X
X
Deploy code with GIT, FTP
X
X
Service Fabric allows you to have multiple environments for your apps or to deploy different versions of your app side-by-side. Automatic OS updates are planned for a future Service Fabric release.
X
FEATURE
APP SERVICE (WEB APPS)
CLOUD SERVICES (WEB ROLES)
VIRTUAL MACHINES
SERVICE FABRIC
Deploy code with Web Deploy
X
X
WebMatrix support
X
X
Access to services like Service Bus, Storage, SQL Database
X
X
X
X
Host web or web services tier of a multi-tier architecture
X
X
X
X
Host middle tier of a multi-tier architecture
X
X
X
X
NOTES
Cloud Services supports the use of Web Deploy to deploy updates to individual role instances. However, you can't use it for initial deployment of a role, and if you use Web Deploy for an update you have to deploy separately to each instance of a role. Multiple instances are required in order to qualify for the Cloud Service SLA for production environments.
App Service web apps can easily host a REST API middle tier, and the WebJobs feature can host background processing jobs. You can run WebJobs in a dedicated website to achieve independent scalability for the tier. The preview API apps feature provides even more features for hosting REST services.
APP SERVICE (WEB APPS)
CLOUD SERVICES (WEB ROLES)
VIRTUAL MACHINES
Integrated MySQL-as-aservice support
X
X
X
Support for ASP.NET, classic ASP, Node.js, PHP, Python
X
X
X
X
Service Fabric supports the creation of a web front-end using ASP.NET 5 or you can deploy any type of application (Node.js, Java, etc) as a guest executable.
Scale out to multiple instances without redeploy
X
X
X
X
Virtual Machines can scale out to multiple instances, but the services running on them must be written to handle this scale-out. You have to configure a load balancer to route requests across the machines, and create an Affinity Group to prevent simultaneous restarts of all instances due to maintenance or hardware failures.
Support for SSL
X
X
X
X
For App Service web apps, SSL for custom domain names is only supported for Basic and Standard mode. For information about using SSL with web apps, see Configuring an SSL certificate for an Azure Website.
FEATURE
SERVICE FABRIC
NOTES
Cloud Services can integrate MySQL-as-aservice through ClearDB's offerings, but not as part of the Azure Portal workflow.
APP SERVICE (WEB APPS)
CLOUD SERVICES (WEB ROLES)
VIRTUAL MACHINES
SERVICE FABRIC
Visual Studio integration
X
X
X
X
Remote Debugging
X
X
X
Deploy code with TFS
X
X
X
X
Network isolation with Azure Virtual Network
X
X
X
X
Support for Azure Traffic Manager
X
X
X
X
Integrated Endpoint Monitoring
X
X
X
Remote desktop access to servers
X
X
X
Install any custom MSI
X
X
X
Ability to define/execute start-up tasks
X
X
X
Can listen to ETW events
X
X
X
FEATURE
NOTES
See also Azure Websites Virtual Network Integration
Service Fabric allows you to host any executable file as a guest executable or you can install any app on the VMs.
Scenarios and recommendations Here are some common application scenarios with recommendations as to which Azure web hosting option might be most appropriate for each. I need a web front end with background processing and database backend to run business applications integrated with on premise assets. I need a reliable way to host my corporate website that scales well and offers global reach. I have an IIS6 application running on Windows Server 2003. I'm a small business owner, and I need an inexpensive way to host my site but with future growth in mind. I'm a web or graphic designer, and I want to design and build web sites for my customers. I'm migrating my multi-tier application with a web front-end to the Cloud. My application depends on highly customized Windows or Linux environments and I want to move it to the
cloud. My site uses open source software, and I want to host it in Azure. I have a line-of-business application that needs to connect to the corporate network. I want to host a REST API or web service for mobile clients. I need a web front end with background processing and database backend to run business applications integrated with on premise assets. Azure App Service is a great solution for complex business applications. It lets you develop apps that scale automatically on a load balanced platform, are secured with Active Directory, and connect to your on-premises resources. It makes managing those apps easy through a world-class portal and APIs, and allows you to gain insight into how customers are using them with app insight tools. The Webjobs feature lets you run background processes and tasks as part of your web tier, while hybrid connectivity and VNET features make it easy to connect back to on-premises resources. Azure App Service provides three 9's SLA for web apps and enables you to: Run your applications reliably on a self-healing, auto-patching cloud platform. Scale automatically across a global network of datacenters. Back up and restore for disaster recovery. Be ISO, SOC2, and PCI compliant. Integrate with Active Directory I need a reliable way to host my corporate website that scales well and offers global reach. Azure App Service is a great solution for hosting corporate websites. It enables web apps to scale quickly and easily to meet demand across a global network of datacenters. It offers local reach, fault tolerance, and intelligent traffic management. All on a platform that provides world-class management tools, allowing you to gain insight into site health and site traffic quickly and easily. Azure App Service provides three 9's SLA for web apps and enables you to: Run your websites reliably on a self-healing, auto-patching cloud platform. Scale automatically across a global network of datacenters. Back up and restore for disaster recovery. Manage logs and traffic with integrated tools. Be ISO, SOC2, and PCI compliant. Integrate with Active Directory I have an IIS6 application running on Windows Server 2003. Azure App Service makes it easy to avoid the infrastructure costs associated with migrating older IIS6 applications. Microsoft has created easy to use migration tools and detailed migration guidance that enable you to check compatibility and identify any changes that need to be made. Integration with Visual Studio, TFS, and common CMS tools makes it easy to deploy IIS6 applications directly to the cloud. Once deployed, the Azure Portal provides robust management tools that enable you to scale down to manage costs and up to meet demand as necessary. With the migration tool you can: Quickly and easily migrate your legacy Windows Server 2003 web application to the cloud. Opt to leave your attached SQL database on-premise to create a hybrid application. Automatically move your SQL database along with your legacy application. I'm a small business owner, and I need an inexpensive way to host my site but with future growth in mind. Azure App Service is a great solution for this scenario, because you can start using it for free and then add more capabilities when you need them. Each free web app comes with a domain provided by Azure (your_company.azurewebsites.net), and the platform includes integrated deployment and management tools as well as an application gallery that make it easy to get started. There are many other services and scaling options that allow the site to evolve with increased user demand. With Azure App Service, you can: Begin with the free tier and then scale up as needed.
Use the Application Gallery to quickly set up popular web applications, such as WordPress. Add additional Azure services and features to your application as needed. Secure your web app with HTTPS. I'm a web or graphic designer, and I want to design and build websites for my customers For web developers and designers, Azure App Service integrates easily with a variety of frameworks and tools, includes deployment support for Git and FTP, and offers tight integration with tools and services such as Visual Studio and SQL Database. With App Service, you can: Use command-line tools for automated tasks. Work with popular languages such as .Net, PHP, Node.js, and Python. Select three different scaling levels for scaling up to very high capacities. Integrate with other Azure services, such as SQL Database, Service Bus and Storage, or partner offerings from the Azure Store, such as MySQL and MongoDB. Integrate with tools such as Visual Studio, Git, WebMatrix, WebDeploy, TFS, and FTP. I'm migrating my multi-tier application with a web front-end to the Cloud If you’re running a multi-tier application, such as a web server that connects to a database, Azure App Service is a good option that offers tight integration with Azure SQL Database. And you can use the WebJobs feature for running backend processes. Choose Service Fabric for one or more of your tiers if you need more control over the server environment, such as the ability to remote into your server or configure server startup tasks. Choose Virtual Machines for one or more of your tiers if you want to use your own machine image or run server software or services that you can't configure on Service Fabric. My application depends on highly customized Windows or Linux environments and I want to move it to the cloud. If your application requires complex installation or configuration of software and the operating system, Virtual Machines is probably the best solution. With Virtual Machines, you can: Use the Virtual Machine gallery to start with an operating system, such as Windows or Linux, and then customize it for your application requirements. Create and upload a custom image of an existing on-premises server to run on a virtual machine in Azure. My site uses open source software, and I want to host it in Azure If your open source framework is supported on App Service, the languages and frameworks needed by your application are configured for you automatically. App Service enables you to: Use many popular open source languages, such as .NET, PHP, Node.js, and Python. Set up WordPress, Drupal, Umbraco, DNN, and many other third-party web applications. Migrate an existing application or create a new one from the Application Gallery. If your open source framework is not supported on App Service, you can run it on one of the other Azure web hosting options. With Virtual Machines, you install and configure the software on the machine image, which can be Windows or Linux-based. I have a line -of-business application that needs to connect to the corporate network If you want to create a line-of-business application, your website might require direct access to services or data on the corporate network. This is possible on App Service, Service Fabric, and Virtual Machines using the Azure Virtual Network service. On App Service you can use the VNET integration feature, which allows your Azure applications to run as if they were on your corporate network. I want to host a REST API or web service for mobile clients
HTTP-based web services enable you to support a wide variety of clients, including mobile clients. Frameworks like ASP.NET Web API integrate with Visual Studio to make it easier to create and consume REST services. These services are exposed from a web endpoint, so it is possible to use any web hosting technique on Azure to support this scenario. However, App Service is a great choice for hosting REST APIs. With App Service, you can: Quickly create a mobile app or API app to host the HTTP web service in one of Azure’s globally distributed datacenters. Migrate existing services or create new ones. Achieve SLA for availability with a single instance, or scale out to multiple dedicated machines. Use the published site to provide REST APIs to any HTTP clients, including mobile clients. NOTE If you want to get started with Azure App Service before signing up for an account, go to https://trywebsites.azurewebsites.net, where you can immediately create a short-lived starter app in Azure App Service for free. No credit card required, no commitments.
Next Steps For more information about the three web hosting options, see Introducing Azure. To get started with the chosen options for your application, see the following resources: Azure App Service Azure Cloud Services Azure Virtual Machines Service Fabric
1 min to read • Edit O nline
Create a virtual machine running Windows in the Azure portal 6/1/2017 • 3 min to read • Edit Online
IMPORTANT Azure has two different deployment models for creating and working with resources: Resource Manager and Classic. This article covers using the Classic deployment model. Microsoft recommends that most new deployments use the Resource Manager model. Learn how to perform these steps using the Resource Manager deployment model using the Azure portal.
This tutorial shows you how to create an Azure virtual machine (VM) running Windows in the Azure portal. We'll use a Windows Server image as an example, but that's just one of the many images Azure offers. Note that your image choices depend on your subscription. For example, Windows desktop images may be available to MSDN subscribers. This section shows you how to use the Dashboard in the Azure portal to select and then create the virtual machine. You can also create VMs using your own images. To learn about this and other methods, see Different ways to create a Windows virtual machine.
Create the virtual machine 1. Sign in to the Azure portal. 2. Starting in the upper left, click New > Compute > Windows Server 2016 Datacenter.
3. On the Windows Server 2016 Datacenter, select the Classic deployment model. Click Create.
1. Basics blade The Basics blade requests administrative information for the virtual machine. 1. Enter a Name for the virtual machine. In the example, HeroVM is the name of the virtual machine. The name must be 1-15 characters long and it cannot contain special characters. 2. Enter a User name and a strong Password that are used to create a local account on the VM. The local account is used to sign in to and manage the VM. In the example, azureuser is the user name. The password must be 8-123 characters long and meet three out of the four following complexity requirements: one lower case character, one upper case character, one number, and one special character. See more about username and password requirements. 3. The Subscription is optional. One common setting is "Pay-As-You-Go". 4. Select an existing Resource group or type the name for a new one. In the example, HeroVMRG is the name of the resource group. 5. Select an Azure datacenter Location where you want the VM to run. In the example, East US is the location. 6. When you are done, click Next to continue to the next blade.
2. Size blade The Size blade identifies the configuration details of the VM, and lists various choices that include OS, number of processors, disk storage type, and estimated monthly usage costs. Choose a VM size, and then click Select to continue. In this example, DS1_V2 Standard is the VM size.
3. Settings blade The Settings blade requests storage and network options. You can accept the default settings. Azure creates appropriate entries where necessary. If you selected a virtual machine size that supports it, you can try Azure Premium Storage by selecting Premium (SSD) in Disk type. When you're done making changes, click OK.
4. Summary blade The Summary blade lists the settings specified in the previous blades. Click OK when you're ready to make the image.
After the virtual machine is created, the portal lists the new virtual machine under All resources, and displays a tile of the virtual machine on the dashboard. The corresponding cloud service and storage account also are created and listed. Both the virtual machine and cloud service are started automatically and their status is listed as Running.
Next steps Learn how to create a VM using the Resource Manager deployment model in the Azure portal. Log on to the virtual machine. For instructions, see Log on to a virtual machine running Windows Server. Attach a disk to store data. You can attach both empty disks and disks that contain data. For instructions, see the Attach a data disk to a Windows virtual machine created with the classic deployment model.
Log on to a Windows virtual machine using the Azure portal 6/1/2017 • 2 min to read • Edit Online
In the Azure portal, you use the Connect button to start a Remote Desktop session and log on to a Windows VM. Do you want to connect to a Linux VM? See How to log on to a virtual machine running Linux. IMPORTANT Azure has two different deployment models for creating and working with resources: Resource Manager and Classic. This article covers using the Classic deployment model. Microsoft recommends that most new deployments use the Resource Manager model. For information about how to log on to a VM using the Resource Manager model, see here.
Connect to the virtual machine 1. Sign in to the Azure portal. 2. Click on the virtual machine that you want to access. The name is listed in the All resources pane.
3. Click Connect on the command bar atop the virtual machine dashboard.
Log on to the virtual machine 1. Clicking Connect creates and downloads a Remote Desktop Protocol file (.rdp file). Click Open to use this file. 2. You will get a warning that the .rdp is from an unknown publisher. This is normal. In the Remote Desktop window, click Connect to continue.
3. In the Windows Security window, type the credentials for an account on the virtual machine and then click OK. Local account - this is usually the local account user name and password that you specified when you created the virtual machine. In this case, the domain is the name of the virtual machine and it is entered as vmname\username. Domain joined VM - if the VM belongs to a domain, enter the user name in the format Domain\Username. The account also needs to either be in the Administrators group or have been granted remote access privileges to the VM. Domain controller - if the VM is a domain controller, type the user name and password of a domain administrator account for that domain. 4. Click Yes to verify the identity of the virtual machine and finish logging on.
Next steps If the Connect button is inactive or you are having other problems with the Remote Desktop connection, try resetting the configuration. click Reset remote access from the virtual machine dashboard.
For problems with your password, try resetting it. Click Reset password along the left edge of virtual machine dashboard, under Support + Troubleshooting.
If those tips don't work or aren't what you need, see Troubleshoot Remote Desktop connections to a Windowsbased Azure Virtual Machine. This article walks you through diagnosing and resolving common problems.
Install the Azure CLI 1.0 4/27/2017 • 3 min to read • Edit Online
IMPORTANT This topic describes how to install the Azure CLI 1.0, which is built on nodeJs and supports all classic deployment API calls as well as a large number of Resource Manager deployment activities. You should use the Azure CLI 2.0 for new or forwardlooking CLI deployments and management.
Quickly install the Azure Command-Line Interface (Azure CLI 1.0) to use a set of open-source shell-based commands for creating and managing resources in Microsoft Azure. You have several options to install these cross-platform tools on your computer: npm package - Run npm (the package manager for JavaScript) to install the latest Azure CLI 1.0 package on your Linux distribution or OS. Requires node.js and npm on your computer. Installer - Download an installer for easy installation on Mac or Windows. Docker container - Start using the latest CLI in a ready-to-run Docker container. Requires Docker host on your computer. For more options and background, see the project repository on GitHub. Once the Azure CLI 1.0 is installed, connect it with your Azure subscription and run the azure commands from your command-line interface (Bash, Terminal, Command prompt, and so on) to work with your Azure resources.
Option 1: Install an npm package To install the CLI from an npm package, make sure you have downloaded and installed the latest Node.js and npm. Then, run npm install to install the azure-cli package: npm install -g azure-cli
On Linux distributions, you might need to use sudo to successfully run the npm command, as follows: sudo npm install -g azure-cli
NOTE If you need to install or update Node.js and npm on your Linux distribution or OS, we recommend that you install the most recent Node.js LTS version (4.x). If you use an older version, you might get installation errors.
If you prefer, download the latest Linux tar file for the npm package locally. Then, install the downloaded npm package as follows (on Linux distributions you might need to use sudo): npm install -g
Option 2: Use an installer
If you use a Mac or Windows computer, the following CLI installers are available for download: Mac OS X installer Windows MSI TIP On Windows, you can also download the Web Platform Installer to install the CLI. This installer gives you the option to install additional Azure SDK and command-line tools after installing the CLI.
Option 3: Use a Docker container If you have set up your computer as a Docker host, you can run the latest Azure CLI 1.0 in a Docker container. Run the following command (on Linux distributions you might need to use sudo): docker run -it microsoft/azure-cli
Run Azure CLI 1.0 commands After the Azure CLI 1.0 is installed, run the azure command from your command-line user interface (Bash, Terminal, Command prompt, and so on). For example, to run the help command, type the following: azure help
NOTE On some Linux distributions, you may receive an error similar to /usr/bin/env: ‘node’: No such file or directory . This error comes from recent installations of Node.js being installed at /usr/bin/nodejs. To fix it, create a symbolic link to /usr/bin/node by running this command:
sudo ln -s /usr/bin/nodejs /usr/bin/node
To see the version of the Azure CLI 1.0 you installed, type the following: azure --version
Now you are ready! To access all the CLI commands to work with your own resources, connect to your Azure subscription from the Azure CLI. NOTE When you first use Azure CLI, you see a message asking if you want to allow Microsoft to collect usage information. Participation is voluntary. If you choose to participate, you can stop at any time by running azure telemetry --disable . To enable participation at any time, run azure telemetry --enable .
Update the CLI Microsoft frequently releases updated versions of the Azure CLI. Reinstall the CLI using the installer for your operating system, or run the latest Docker container. Or, if you have the latest Node.js and npm installed, update by
typing the following (on Linux distributions you might need to use sudo). npm update -g azure-cli
Enable tab completion Tab completion of CLI commands is supported for Mac and Linux. To enable it in zsh, run: echo '. <(azure --completion)' >> .zshrc
To enable it in bash, run: azure --completion >> ~/azure.completion.sh echo 'source ~/azure.completion.sh' >> ~/.bash_profile
Next steps Connect from the CLI to your Azure subscription to create and manage Azure resources. To learn more about the Azure CLI, download source code, report problems, or contribute to the project, visit the GitHub repository for the Azure CLI. If you have questions about using the Azure CLI, or Azure, visit the Azure Forums.
Attach a data disk to a Windows virtual machine created with the classic deployment model 4/3/2017 • 3 min to read • Edit Online
This article shows you how to attach new and existing disks created with the Classic deployment model to a Windows virtual machine using the Azure portal. You can also attach a data disk to a Linux VM in the Azure portal. Before you attach a disk, review these tips: The size of the virtual machine controls how many data disks you can attach. For details, see Sizes for virtual machines. To use Premium storage, you need a DS-series or GS-series virtual machine. You can use disks from both Premium and Standard storage accounts with these virtual machines. Premium storage is available in certain regions. For details, see Premium Storage: High-Performance Storage for Azure Virtual Machine Workloads. For a new disk, you don't need to create it first because Azure creates it when you attach it. You can also attach a data disk using Powershell. IMPORTANT Azure has two different deployment models for creating and working with resources: Resource Manager and Classic.
Find the virtual machine 1. Sign in to the Azure portal. 2. Select the virtual machine from the resource listed on the dashboard. 3. In the left pane under Settings, click Disks.
Continue by following instructions for attaching either a new disk or an existing disk.
Option 1: Attach and initialize a new disk 1. On the Disks blade, click Attach new. 2. Review the default settings, update as necessary, and then click OK.
3. After Azure creates the disk and attaches it to the virtual machine, the new disk is listed in the virtual machine's disk settings under Data Disks. Initialize a new data disk 1. Connect to the virtual machine. For instructions, see How to connect and log on to an Azure virtual machine running Windows. 2. After you log on to the virtual machine, open Server Manager. In the left pane, select File and Storage Services.
3. Select Disks. 4. The Disks section lists the disks. Most often, a virtual machine has disk 0, disk 1, and disk 2. Disk 0 is the operating system disk, disk 1 is the temporary disk, and disk 2 is the data disk newly attached to the virtual machine. The data disk lists the Partition as Unknown. Right-click the disk and select Initialize. 5. You're notified that all data will be erased when the disk is initialized. Click Yes to acknowledge the warning and initialize the disk. Once complete, the partition will be listed as GPT. Right-click the disk again and select
New Volume. 6. Complete the wizard using the default values. When the wizard is done, the Volumes section lists the new volume. The disk is now online and ready to store data.
Option 2: Attach an existing disk 1. On the Disks blade, click Attach existing. 2. Under Attach existing disk, click Location.
3. Under Storage accounts, select the account and container that holds the .vhd file.
4. Select the .vhd file. 5. Under Attach existing disk, the file you just selected is listed under VHD File. Click OK. 6. After Azure attaches the disk to the virtual machine, it's listed in the virtual machine's disk settings under Data Disks.
Use TRIM with standard storage If you use standard storage (HDD), you should enable TRIM. TRIM discards unused blocks on the disk so you are only billed for storage that you are actually using. Using TRIM can save costs, including unused blocks that result from deleting large files. You can run this command to check the TRIM setting. Open a command prompt on your Windows VM and type: fsutil behavior query DisableDeleteNotify
If the command returns 0, TRIM is enabled correctly. If it returns 1, run the following command to enable TRIM:
fsutil behavior set DisableDeleteNotify 0
Next steps If your application needs to use the D: drive to store data, you can change the drive letter of the Windows temporary disk.
Additional resources About disks and VHDs for virtual machines
How to detach a disk from a Windows virtual machine 3/27/2017 • 1 min to read • Edit Online
IMPORTANT Azure has two distinct deployment models for creating and working with resources: Resource Manager and Classic. This article covers using the Classic deployment model. Microsoft recommends that most new deployments use the Resource Manager model. For information about how to detach a disk using the Resource Manager model, see here.
When you no longer need a data disk that's attached to a virtual machine, you can easily detach it. Detaching a disk removes the disk from the virtual machine, but doesn't delete the disk from the Azure storage account. If you want to use the existing data on the disk again, you can reattach it to the same virtual machine, or another one. NOTE To detach an operating system disk, you first need to delete the virtual machine.
Find the disk If you don't know the name of the disk or want to verify it before you detach it, follow these steps. 1. Sign in to the Azure portal. 2. Click Virtual Machines, and then select the appropriate VM. 3. Click Disks along the left edge of the virtual machine dashboard, under Settings. The virtual machine dashboard lists the name and type of all attached disks. For example, this screen shows a virtual machine with one operating system (OS) disk and one data disk:
Detach the disk 1. From the Azure portal, click Virtual Machines, and then click the name of the virtual machine that has the data disk you want to detach. 2. Click Disks along the left edge of the virtual machine dashboard, under Settings. 3. Click the disk you want to detach.
4. From the command bar, click Detach.
5. In the confirmation window, click Yes to detach the disk.
The disk remains in storage but is no longer attached to a virtual machine.
Additional resources About disks and VHDs for virtual machines How to attach a data disk to a Windows virtual machine
1 min to read • Edit O nline
How to set up endpoints on a classic Windows virtual machine in Azure 6/1/2017 • 5 min to read • Edit Online
All Windows virtual machines that you create in Azure using the classic deployment model can automatically communicate over a private network channel with other virtual machines in the same cloud service or virtual network. However, computers on the Internet or other virtual networks require endpoints to direct the inbound network traffic to a virtual machine. This article is also available for Linux virtual machines. IMPORTANT Azure has two different deployment models for creating and working with resources: Resource Manager and Classic. This article covers using the Classic deployment model. Microsoft recommends that most new deployments use the Resource Manager model.
In the Resource Manager deployment model, endpoints are configured using Network Security Groups (NSGs). For more information, see Allow external access to your VM using the Azure Portal. When you create a Windows virtual machine in the Azure portal, common endpoints like those for Remote Desktop and Windows PowerShell Remoting are typically created for you automatically. You can configure additional endpoints while creating the virtual machine or afterwards as needed. Each endpoint has a public port and a private port: The public port is used by the Azure load balancer to listen for incoming traffic to the virtual machine from the Internet. The private port is used by the virtual machine to listen for incoming traffic, typically destined to an application or service running on the virtual machine. Default values for the IP protocol and TCP or UDP ports for well-known network protocols are provided when you create endpoints with the Azure classic portal. For custom endpoints, you'll need to specify the correct IP protocol (TCP or UDP) and the public and private ports. To distribute incoming traffic randomly across multiple virtual machines, you'll need to create a load-balanced set consisting of multiple endpoints. After you create an endpoint, you can use an access control list (ACL) to define rules that permit or deny the incoming traffic to the public port of the endpoint based on its source IP address. However, if the virtual machine is in an Azure virtual network, you should use network security groups instead. For details, see About network security groups. NOTE Firewall configuration for Azure virtual machines is done automatically for ports associated with remote connectivity endpoints that Azure sets up automatically. For ports specified for all other endpoints, no configuration is done automatically to the firewall of the virtual machine. When you create an endpoint for the virtual machine, you'll need to ensure that the firewall of the virtual machine also allows the traffic for the protocol and private port corresponding to the endpoint configuration. To configure the firewall, see the documentation or on-line help for the operating system running on the virtual machine.
Create an endpoint
1. If you haven't already done so, sign in to the Azure classic portal. 2. Click Virtual Machines, and then click the name of the virtual machine that you want to configure. 3. Click Endpoints. The Endpoints page lists all the current endpoints for the virtual machine. (This example is a Windows VM. A Linux VM will by default show an endpoint for SSH.)
4. In the taskbar, click Add. 5. On the Add an endpoint to a virtual machine page, choose the type of endpoint.
6.
7. 8.
9.
10.
If you're creating a new endpoint that isn't part of a load-balanced set, or is the first endpoint in a new load-balanced set, choose Add a stand-alone endpoint, then click the left arrow. Otherwise, choose Add an endpoint to an existing load-balanced set, select the name of the loadbalanced set, then click the left arrow. On the Specify the details of the endpoint page, type a name for the endpoint, then click the check mark to create the endpoint. On the Specify the details of the endpoint page, type a name for the endpoint in Name. You can also choose a network protocol name from the list, which will fill in initial values for the Protocol, Public Port, and Private Port. For a customized endpoint, in Protocol, choose either TCP or UDP. For customized ports, in Public Port, type the port number for the incoming traffic from the Internet. In Private Port, type the port number on which the virtual machine is listening. These port numbers can be different. Ensure that the firewall on the virtual machine has been configured to allow the traffic corresponding to the protocol (in step 7) and private port. If this endpoint will be the first one in a load-balanced set, click Create a load-balanced set, and then click the right arrow. On the Configure the load-balanced set page, specify a load-balanced set name, a probe protocol and port, and the probe interval and number of probes sent. The Azure load balancer sends probes to the virtual machines in a load-balanced set to monitor their availability. The Azure load balancer does not forward traffic to virtual machines that do not respond to the probe. Click the right arrow. Click the check mark to create the endpoint.
The new endpoint will be listed on the Endpoints page.
Manage the ACL on an endpoint To define the set of computers that can send traffic, the ACL on an endpoint can restrict traffic based upon source IP address. Follow these steps to add, modify, or remove an ACL on an endpoint. NOTE If the endpoint is part of a load-balanced set, any changes you make to the ACL on an endpoint are applied to all endpoints in the set.
If the virtual machine is in an Azure virtual network, we recommend network security groups instead of ACLs. For details, see About network security groups. 1. If you haven't already done so, sign in to the Azure classic portal. 2. Click Virtual Machines, and then click the name of the virtual machine that you want to configure. 3. Click Endpoints. From the list, select the appropriate endpoint.
4. In the taskbar, click Manage ACL to open the Specify ACL details dialog box.
5. Use rows in the list to add, delete, or edit rules for an ACL and change their order. The Remote Subnet value is an IP address range for incoming traffic from the Internet that the Azure load balancer uses to permit or deny the traffic based on its source IP address. Be sure to specify the IP address range in CIDR format, also known as address prefix format. An example is 131.107.0.0/16. You can use rules to allow only traffic from specific computers corresponding to your computers on the Internet or to deny traffic from specific, known address ranges. The rules are evaluated in order starting with the first rule and ending with the last rule. This means that rules should be ordered from least restrictive to most restrictive. For examples and more information, see What is a Network Access Control List?.
Next steps
To use an Azure PowerShell cmdlet to set up a VM endpoint, see Add-AzureEndpoint. To use an Azure PowerShell cmdlet to manage an ACL on an endpoint, see Managing access control lists (ACLs) for endpoints by using PowerShell. If you created a virtual machine in the Resource Manager deployment model, you can use Azure PowerShell to create network security groups to control traffic to the VM.
Connect Windows virtual machines created with the classic deployment model with a virtual network or cloud service 6/6/2017 • 3 min to read • Edit Online
IMPORTANT Azure has two different deployment models for creating and working with resources: Resource Manager and Classic. This article covers using the Classic deployment model. Microsoft recommends that most new deployments use the Resource Manager model.
Windows virtual machines created with the classic deployment model are always placed in a cloud service. The cloud service acts as a container and provides a unique public DNS name, a public IP address, and a set of endpoints to access the virtual machine over the Internet. The cloud service can be in a virtual network, but that's not a requirement. You can also connect Linux virtual machines with a virtual network or cloud service. If a cloud service isn't in a virtual network, it's called a standalone cloud service. The virtual machines in a standalone cloud service communicate with other virtual machines by using the other virtual machines’ public DNS names, and the traffic travels over the Internet. If a cloud service is in a virtual network, the virtual machines in that cloud service can communicate with all other virtual machines in the virtual network without sending any traffic over the Internet. If you place your virtual machines in the same standalone cloud service, you can still use load balancing and availability sets. For details, see Load balancing virtual machines and Manage the availability of virtual machines. However, you can't organize the virtual machines on subnets or connect a standalone cloud service to your onpremises network. Here's an example:
If you place your virtual machines in a virtual network, you can decide how many cloud services you want to use for load balancing and availability sets. Additionally, you can organize the virtual machines on subnets in the same way as your on-premises network and connect the virtual network to your on-premises network. Here's an example:
Virtual networks are the recommended way to connect virtual machines in Azure. The best practice is to configure each tier of your application in a separate cloud service. However, you may need to combine some virtual machines from different application tiers into the same cloud service to remain within the maximum of 200 cloud services per subscription. To review this and other limits, see Azure Subscription and Service Limits, Quotas, and Constraints.
Connect VMs in a virtual network To connect virtual machines in a virtual network: 1. Create the virtual network in the Azure portal and specify 'classic deployment'. 2. Create the set of cloud services for your deployment to reflect your design for availability sets and load balancing. In the Azure portal, click New > Compute > Cloud service for each cloud service. As you fill out the cloud service details, choose the same resource group used with the virtual network. 3. To create each new virtual machine, click New > Compute, then select the appropriate VM image from the Featured apps. In the VM Basics blade, choose the same resource group used with the virtual network.
4. As you fill out the VM Settings, choose the correct Cloud service or virtual network for the VM. Azure will select the other item based on your selection.
Connect VMs in a standalone cloud service To connect virtual machines in a standalone cloud service: 1. Create the cloud service in the Azure portal. Click New > Compute > Cloud service. Or, you can create the cloud service for your deployment when you create your first virtual machine. 2. When you create the virtual machines, choose the same resource group used with the cloud service.
3. As you fill out the VM details, choose the name of cloud service created in the first step.
Next steps After you create a virtual machine, it's a good idea to add a data disk so your services and workloads have a location to store data.
Connect virtual networks from different deployment models using PowerShell 4/27/2017 • 14 min to read • Edit Online
This article shows you how to connect classic VNets to Resource Manager VNets to allow the resources located in the separate deployment models to communicate with each other. The steps in this article use PowerShell, but you can also create this configuration using the Azure portal by selecting the article from this list. Connecting a classic VNet to a Resource Manager VNet is similar to connecting a VNet to an on-premises site location. Both connectivity types use a VPN gateway to provide a secure tunnel using IPsec/IKE. You can create a connection between VNets that are in different subscriptions and in different regions. You can also connect VNets that already have connections to on-premises networks, as long as the gateway that they have been configured with is dynamic or route-based. For more information about VNet-to-VNet connections, see the VNet-to-VNet FAQ at the end of this article. If your VNets are in the same region, you may want to instead consider connecting them using VNet Peering. VNet peering does not use a VPN gateway. For more information, see VNet peering.
Before beginning The following steps walk you through the settings necessary to configure a dynamic or route-based gateway for each VNet and create a VPN connection between the gateways. This configuration does not support static or policybased gateways. Prerequisites Both VNets have already been created. The address ranges for the VNets do not overlap with each other, or overlap with any of the ranges for other connections that the gateways may be connected to. You have installed the latest PowerShell cmdlets. See How to install and configure Azure PowerShell for more information. Make sure you install both the Service Management (SM) and the Resource Manager (RM) cmdlets. Example settings You can use these values to create a test environment, or refer to them to better understand the examples in this article. Classic VNet settings VNet Name = ClassicVNet Location = West US Virtual Network Address Spaces = 10.0.0.0/24 Subnet-1 = 10.0.0.0/27 GatewaySubnet = 10.0.0.32/29 Local Network Name = RMVNetLocal GatewayType = DynamicRouting Resource Manager VNet settings VNet Name = RMVNet Resource Group = RG1 Virtual Network IP Address Spaces = 192.168.0.0/16 Subnet-1 = 192.168.1.0/24
GatewaySubnet = 192.168.0.0/26 Location = East US Gateway public IP name = gwpip Local Network Gateway = ClassicVNetLocal Virtual Network Gateway name = RMGateway Gateway IP addressing configuration = gwipconfig
Section 1 - Configure the classic VNet Part 1 - Download your network configuration file 1. Log in to your Azure account in the PowerShell console with elevated rights. The following cmdlet prompts you for the login credentials for your Azure Account. After logging in, it downloads your account settings so that they are available to Azure PowerShell. You use the SM PowerShell cmdlets to complete this part of the configuration. Add-AzureAccount
2. Export your Azure network configuration file by running the following command. You can change the location of the file to export to a different location if necessary. Get-AzureVNetConfig -ExportToFile C:\AzureNet\NetworkConfig.xml
3. Open the .xml file that you downloaded to edit it. For an example of the network configuration file, see the Network Configuration Schema. Part 2 -Verify the gateway subnet In the VirtualNetworkSites element, add a gateway subnet to your VNet if one has not already been created. When working with the network configuration file, the gateway subnet MUST be named "GatewaySubnet" or Azure cannot recognize and use it as a gateway subnet. IMPORTANT When working with gateway subnets, avoid associating a network security group (NSG) to the gateway subnet. Associating a network security group to this subnet may cause your VPN gateway to stop functioning as expected. For more information about network security groups, see What is a network security group?
Example: 10.0.0.0/2410.0.0.0/2710.0.0.32/29
Part 3 - Add the local network site The local network site you add represents the RM VNet to which you want to connect. Add a LocalNetworkSites element to the file if one doesn't already exist. At this point in the configuration, the VPNGatewayAddress can be any valid public IP address because we haven't yet created the gateway for the Resource Manager VNet. Once we create the gateway, we replace this placeholder IP address with the correct public IP address that has been assigned to the RM gateway. 192.168.0.0/1613.68.210.16
Part 4 - Associate the VNet with the local network site In this section, we specify the local network site that you want to connect the VNet to. In this case, it is the Resource Manager VNet that you referenced earlier. Make sure the names match. This step does not create a gateway. It specifies the local network that the gateway will connect to.
Part 5 - Save the file and upload Save the file, then import it to Azure by running the following command. Make sure you change the file path as necessary for your environment. Set-AzureVNetConfig -ConfigurationPath C:\AzureNet\NetworkConfig.xml
You will see a similar result showing that the import succeeded. OperationDescription -------------------Set-AzureVNetConfig
OperationId ----------e0ee6e66-9167-cfa7-a746-7casb9
OperationStatus --------------Succeeded
Part 6 - Create the gateway Before running this example, refer to the network configuration file that you downloaded for the exact names that Azure expects to see. The network configuration file contains the values for your classic virtual networks. Sometimes the names for classic VNets are changed in the network configuration file when creating classic VNet settings in the Azure portal due to the differences in the deployment models. For example, if you used the Azure portal to create a classic VNet named 'Classic VNet' and created it in a resource group named 'ClassicRG', the name that is contained in the network configuration file is converted to 'Group ClassicRG Classic VNet'. When specifying the name of a VNet that contains spaces, use quotation marks around the value. Use the following example to create a dynamic routing gateway:
New-AzureVNetGateway -VNetName ClassicVNet -GatewayType DynamicRouting
You can check the status of the gateway by using the Get-AzureVNetGateway cmdlet.
Section 2: Configure the RM VNet gateway To create a VPN gateway for the RM VNet, follow the following instructions. Don't start the steps until after you have retrieved the public IP address for the classic VNet's gateway. 1. Log in to your Azure account in the PowerShell console. The following cmdlet prompts you for the login credentials for your Azure Account. After logging in, your account settings are downloaded so that they are available to Azure PowerShell. Login-AzureRmAccount
Get a list of your Azure subscriptions if you have more than one subscription. Get-AzureRmSubscription
Specify the subscription that you want to use. Select-AzureRmSubscription -SubscriptionName "Name of subscription"
2. Create a local network gateway. In a virtual network, the local network gateway typically refers to your onpremises location. In this case, the local network gateway refers to your Classic VNet. Give it a name by which Azure can refer to it, and also specify the address space prefix. Azure uses the IP address prefix you specify to identify which traffic to send to your on-premises location. If you need to adjust the information here later, before creating your gateway, you can modify the values and run the sample again. -Name is the name you want to assign to refer to the local network gateway. -AddressPrefix is the Address Space for your classic VNet. -GatewayIpAddress is the public IP address of the classic VNet's gateway. Be sure to change the following sample to reflect the correct IP address. New-AzureRmLocalNetworkGateway -Name ClassicVNetLocal ` -Location "West US" -AddressPrefix "10.0.0.0/24" ` -GatewayIpAddress "n.n.n.n" -ResourceGroupName RG1
3. Request a public IP address to be allocated to the virtual network gateway for the Resource Manager VNet. You can't specify the IP address that you want to use. The IP address is dynamically allocated to the virtual network gateway. However, this does not mean the IP address changes. The only time the virtual network gateway IP address changes is when the gateway is deleted and recreated. It doesn't change across resizing, resetting, or other internal maintenance/upgrades of the gateway. In this step, we also set a variable that is used in a later step. $ipaddress = New-AzureRmPublicIpAddress -Name gwpip ` -ResourceGroupName RG1 -Location 'EastUS' ` -AllocationMethod Dynamic
4. Verify that your virtual network has a gateway subnet. If no gateway subnet exists, add one. Make sure the gateway subnet is named GatewaySubnet.
5. Retrieve the subnet used for the gateway by running the following command. In this step, we also set a variable to be used in the next step. -Name is the name of your Resource Manager VNet. -ResourceGroupName is the resource group that the VNet is associated with. The gateway subnet must already exist for this VNet and must be named GatewaySubnet to work properly. $subnet = Get-AzureRmVirtualNetworkSubnetConfig -Name GatewaySubnet ` -VirtualNetwork (Get-AzureRmVirtualNetwork -Name RMVNet -ResourceGroupName RG1)
6. Create the gateway IP addressing configuration. The gateway configuration defines the subnet and the public IP address to use. Use the following sample to create your gateway configuration. In this step, the -SubnetId and -PublicIpAddressId parameters must be passed the id property from the subnet, and IP address objects, respectively. You can't use a simple string. These variables are set in the step to request a public IP and the step to retrieve the subnet. $gwipconfig = New-AzureRmVirtualNetworkGatewayIpConfig ` -Name gwipconfig -SubnetId $subnet.id ` -PublicIpAddressId $ipaddress.id
7. Create the Resource Manager virtual network gateway by running the following command. The must be RouteBased. It can take 45 minutes or more for the gateway to create.
-VpnType
New-AzureRmVirtualNetworkGateway -Name RMGateway -ResourceGroupName RG1 ` -Location "EastUS" -GatewaySKU Standard -GatewayType Vpn ` -IpConfigurations $gwipconfig ` -EnableBgp $false -VpnType RouteBased
8. Copy the public IP address once the VPN gateway has been created. You use it when you configure the local network settings for your Classic VNet. You can use the following cmdlet to retrieve the public IP address. The public IP address is listed in the return as IpAddress. Get-AzureRmPublicIpAddress -Name gwpip -ResourceGroupName RG1
Section 3: Modify the classic VNet local site settings In this section, you work with the classic VNet. You replace the placeholder IP address that you used when specifying the local site settings that will be used to connect to the Resource Manager VNet gateway. 1. Export the network configuration file. Get-AzureVNetConfig -ExportToFile C:\AzureNet\NetworkConfig.xml
2. Using a text editor, modify the value for VPNGatewayAddress. Replace the placeholder IP address with the public IP address of the Resource Manager gateway and then save the changes. 13.68.210.16
3. Import the modified network configuration file to Azure.
Set-AzureVNetConfig -ConfigurationPath C:\AzureNet\NetworkConfig.xml
Section 4: Create a connection between the gateways Creating a connection between the gateways requires PowerShell. You may need to add your Azure Account to use the classic version of the PowerShell cmdlets. To do so, use Add-AzureAccount. 1. In the PowerShell console, set your shared key. Before running the cmdlets, refer to the network configuration file that you downloaded for the exact names that Azure expects to see. When specifying the name of a VNet that contains spaces, use single quotation marks around the value. In following example, -VNetName is the name of the classic VNet and -LocalNetworkSiteName is the name you specified for the local network site. The -SharedKey is a value that you generate and specify. In the example, we used 'abc123', but you can generate and use something more complex. The important thing is that the value you specify here must be the same value that you specify in the next step when you create your connection. The return should show Status: Successful. Set-AzureVNetGatewayKey -VNetName ClassicVNet ` -LocalNetworkSiteName RMVNetLocal -SharedKey abc123
2. Create the VPN connection by running the following commands: Set the variables. $vnet01gateway = Get-AzureRMLocalNetworkGateway -Name ClassicVNetLocal -ResourceGroupName RG1 $vnet02gateway = Get-AzureRmVirtualNetworkGateway -Name RMGateway -ResourceGroupName RG1
Create the connection. Notice that the -ConnectionType is IPsec, not Vnet2Vnet. New-AzureRmVirtualNetworkGatewayConnection -Name RM-Classic -ResourceGroupName RG1 ` -Location "East US" -VirtualNetworkGateway1 ` $vnet02gateway -LocalNetworkGateway2 ` $vnet01gateway -ConnectionType IPsec -RoutingWeight 10 -SharedKey 'abc123'
Section 5: Verify your connections To verify the connection from your classic VNet to your Resource Manager VNet PowerShell
You can verify that your connection succeeded by using the 'Get-AzureVNetConnection' cmdlet. 1. Use the following cmdlet example, configuring the values to match your own. The name of the virtual network must be in quotes if it contains spaces. Get-AzureVNetConnection "Group ClassicRG ClassicVNet"
2. After the cmdlet has finished, view the values. In the example below, the Connectivity State shows as 'Connected' and you can see ingress and egress bytes.
ConnectivityState EgressBytesTransferred IngressBytesTransferred LastConnectionEstablished LastEventID LastEventMessage from Connecting to LastEventTimeStamp LocalNetworkSiteName
: : : : : :
Connected 181664 182080 1/7/2016 12:40:54 AM 24401 The connectivity state for the local network site 'RMVNetLocal' changed
Connected. : 1/7/2016 12:40:54 AM : RMVNetLocal
Azure portal
In the Azure portal, you can view the connection status for a classic VNet VPN Gateway by navigating to the connection. The following steps show one way to navigate to your connection and verify. 1. In the Azure portal, click All resources and navigate to your classic virtual network. 2. On the virtual network blade, click Overview to access the VPN connections section of the blade. 3. On the VPN connections graphic, click the site.
4. On the Site-to-site VPN connections blade, view the information about your site.
5. To view more information about the connection, click the name of the connection to open the Site-to-site VPN Connection blade.
To verify the connection from your Resource Manager VNet to your classic VNet PowerShell
You can verify that your connection succeeded by using the 'Get-AzureRmVirtualNetworkGatewayConnection' cmdlet, with or without '-Debug'. 1. Use the following cmdlet example, configuring the values to match your own. If prompted, select 'A' in order to run 'All'. In the example, '-Name' refers to the name of the connection that you want to test. Get-AzureRmVirtualNetworkGatewayConnection -Name MyGWConnection -ResourceGroupName MyRG
2. After the cmdlet has finished, view the values. In the example below, the connection status shows as 'Connected' and you can see ingress and egress bytes. "connectionStatus": "Connected", "ingressBytesTransferred": 33509044, "egressBytesTransferred": 4142431
Azure portal
In the Azure portal, you can view the connection status of a Resource Manager VPN Gateway by navigating to the connection. The following steps show one way to navigate to your connection and verify. 1. In the Azure portal, click All resources and navigate to your virtual network gateway. 2. On the blade for your virtual network gateway, click Connections. You can see the status of each connection. 3. Click the name of the connection that you want to verify to open Essentials. In Essentials, you can view more information about your connection. The Status is 'Succeeded' and 'Connected' when you have made a successful connection.
VNet-to-VNet FAQ Does Azure charge for traffic between VNets? VNet-to-VNet traffic within the same region is free for both directions when using a VPN gateway connection. Cross region VNet-to-VNet egress traffic is charged with the outbound inter-VNet data transfer rates based on the source regions. Refer to the VPN Gateway pricing page for details. If you are connecting your VNets using VNet Peering, rather than VPN Gateway, see the Virtual Network pricing page. Does VNet-to -VNet traffic travel across the Internet? No. VNet-to-VNet traffic travels across the Microsoft Azure backbone, not the Internet. Is VNet-to -VNet traffic secure? Yes, it is protected by IPsec/IKE encryption. Do I need a VPN device to connect VNets together? No. Connecting multiple Azure virtual networks together doesn't require a VPN device unless cross-premises connectivity is required. Do my VNets need to be in the same region? No. The virtual networks can be in the same or different Azure regions (locations). Can I use VNet-to -VNet along with multi-site connections? Yes. Virtual network connectivity can be used simultaneously with multi-site VPNs. How many on-premises sites and virtual networks can one virtual network connect to? See Gateway requirements table. Can I use VNet-to -VNet to connect VMs or cloud services outside of a VNet? No. VNet-to-VNet supports connecting virtual networks. It does not support connecting virtual machines or cloud services that are not in a virtual network. Can a cloud service or a load balancing endpoint span VNets? No. A cloud service or a load balancing endpoint can't span across virtual networks, even if they are connected together. Can I used a PolicyBased VPN type for VNet-to -VNet or Multi-Site connections? No. VNet-to-VNet and Multi-Site connections require Azure VPN gateways with RouteBased (previously called Dynamic Routing) VPN types. Can I connect a VNet with a RouteBased VPN Type to another VNet with a PolicyBased VPN type? No, both virtual networks MUST be using route-based (previously called Dynamic Routing) VPNs. Do VPN tunnels share bandwidth? Yes. All VPN tunnels of the virtual network share the available bandwidth on the Azure VPN gateway and the same
VPN gateway uptime SLA in Azure. Are redundant tunnels supported? Redundant tunnels between a pair of virtual networks are supported when one virtual network gateway is configured as active-active. Can I have overlapping address spaces for VNet-to -VNet configurations? No. You can't have overlapping IP address ranges. Can there be overlapping address spaces among connected virtual networks and on-premises local sites? No. You can't have overlapping IP address ranges.
Get started creating an Internet facing load balancer (classic) in the Azure classic portal 1/24/2017 • 3 min to read • Edit Online
An Azure load balancer is a Layer-4 (TCP, UDP) load balancer. The load balancer provides high availability by distributing incoming traffic among healthy service instances in cloud services or virtual machines in a load balancer set. Azure Load Balancer can also present those services on multiple ports, multiple IP addresses, or both. You can configure a load balancer to: Load balance incoming Internet traffic to virtual machines (VMs). We refer to a load balancer in this scenario as an Internet-facing load balancer. Load balance traffic between VMs in a virtual network (VNet), between VMs in cloud services, or between onpremises computers and VMs in a cross-premises virtual network. We refer to a load balancer in this scenario as an internal load balancer (ILB). Forward external traffic to a specific VM instance. IMPORTANT Before you work with Azure resources, it's important to understand that Azure currently has two deployment models: Azure Resource Manager and classic. Make sure you understand deployment models and tools before you work with any Azure resource. You can view the documentation for different tools by clicking the tabs at the top of this article. This article covers the classic deployment model. You can also Learn how to create an Internet facing load balancer using Azure Resource Manager.
The following tasks will be done in this scenario: Create a load balancer that receives network traffic on port 80 and send load-balanced traffic to virtual machines "web1" and "web2" Create NAT rules for remote desktop access/SSH for virtual machines behind the load balancer Create health probes
Set up an Internet-facing load balancer for virtual machines In order to load balance network traffic from the Internet across the virtual machines of a cloud service, you must create a load-balanced set. This procedure assumes that you have already created the virtual machines and that they are all within the same cloud service. To configure a load-balanced set for virtual machines 1. In the Azure classic portal, click Virtual Machines, and then click the name of a virtual machine in the loadbalanced set. 2. Click Endpoints, and then click Add. 3. On the Add an endpoint to a virtual machine page, click the right arrow. 4. On the Specify the details of the endpoint page: In Name, type a name for the endpoint or select the name from the list of predefined endpoints for common protocols. In Protocol, select the protocol required by the type of endpoint, either TCP or UDP, as needed. In Public Port and Private Port, type the port numbers that you want the virtual machine to use, as needed. You can use the private port and firewall rules on the virtual machine to redirect traffic in a way that is appropriate for your application. The private port can be the same as the public port. For example, for an endpoint for web (HTTP) traffic, you could assign port 80 to both the public and private port. 5. Select Create a load-balanced set, and then click the right arrow. 6. On the Configure the load-balanced set page, type a name for the load-balanced set, and then assign the values for probe behavior of the Azure Load Balancer. The Load Balancer uses probes to determine if the virtual machines in the load-balanced set are available to receive incoming traffic. 7. Click the check mark to create the load-balanced endpoint. You will see Yes in the Load-balanced set name column of the Endpoints page for the virtual machine. 8. In the portal, click Virtual Machines, click the name of an additional virtual machine in the load-balanced set, click Endpoints, and then click Add. 9. On the Add an endpoint to a virtual machine page, click Add endpoint to an existing load-balanced set, select the name of the load-balanced set, and then click the right arrow. 10. On the Specify the details of the endpoint page, type a name for the endpoint, and then click the check mark.
For the additional virtual machines in the load-balanced set, repeat steps 8-10.
Next steps Get started configuring an internal load balancer Configure a load balancer distribution mode Configure idle TCP timeout settings for your load balancer
How to create NSGs (classic) in PowerShell 4/27/2017 • 5 min to read • Edit Online
You can use an NSG to control traffic to one or more virtual machines (VMs), role instances, network adapters (NICs), or subnets in your virtual network. An NSG contains access control rules that allow or deny traffic based on traffic direction, protocol, source address and port, and destination address and port. The rules of an NSG can be changed at any time, and changes are applied to all associated instances. For more information about NSGs, visit what is an NSG. IMPORTANT Before you work with Azure resources, it's important to understand that Azure currently has two deployment models: Azure Resource Manager and classic. Make sure you understand deployment models and tools before you work with any Azure resource. You can view the documentation for different tools by clicking the tabs at the top of this article.
This article covers the classic deployment model. You can also create NSGs in the Resource Manager deployment model.
Scenario To better illustrate how to create NSGs, this document will use the scenario below.
In this scenario you will create an NSG for each subnet in the TestVNet virtual network, as described below: NSG-FrontEnd. The front end NSG will be applied to the FrontEnd subnet, and contain two rules: rdp-rule. This rule will allow RDP traffic to the FrontEnd subnet. web-rule. This rule will allow HTTP traffic to the FrontEnd subnet. NSG-BackEnd. The back end NSG will be applied to the BackEnd subnet, and contain two rules: sql-rule. This rule allows SQL traffic only from the FrontEnd subnet. web-rule. This rule denies all internet bound traffic from the BackEnd subnet.
The combination of these rules create a DMZ-like scenario, where the back end subnet can only receive incoming traffic for SQL from the front end subnet, and has no access to the Internet, while the front end subnet can communicate with the Internet, and receive incoming HTTP requests only. The sample PowerShell commands below expect a simple environment already created based on the scenario above. If you want to run the commands as they are displayed in this document, first build the test environment by creating a VNet.
How to create the NSG for the front-end subnet To create an NSG named named NSG-FrontEnd based on the scenario above, follow the steps below: 1. If you have never used Azure PowerShell, see How to Install and Configure Azure PowerShell and follow the instructions all the way to the end to sign into Azure and select your subscription. 2. Create a network security group named NSG-FrontEnd. New-AzureNetworkSecurityGroup -Name "NSG-FrontEnd" -Location uswest ` -Label "Front end subnet NSG"
Expected output: Name
Location
NSG-FrontEnd West US
Label Front end subnet NSG
3. Create a security rule allowing access from the Internet to port 3389. Get-AzureNetworkSecurityGroup -Name "NSG-FrontEnd" ` | Set-AzureNetworkSecurityRule -Name rdp-rule ` -Action Allow -Protocol TCP -Type Inbound -Priority 100 ` -SourceAddressPrefix Internet -SourcePortRange '*' ` -DestinationAddressPrefix '*' -DestinationPortRange '3389'
Expected output:
Name Location Label Rules
: NSG-FrontEnd : Central US : Front end subnet NSG : Type: Inbound
Destination
Name Protocol
Priority Action
Source Address Source Port
Destination
Prefix
Range
Address Prefix
Port
*
*
3389
Range rdp-rule
100
Allow
INTERNET
ALLOW VNET INBOUND
65000
Allow
VIRTUAL_NETWORK *
VIRTUAL_NETWORK *
ALLOW AZURE LOAD
65001
Allow
AZURE_LOADBALAN *
*
*
BALANCER INBOUND DENY ALL INBOUND
65500
Deny
CER *
*
*
TCP * * *
* Type: Outbound
Destination
Name Protocol
Priority Action
Source Address Source Port
Destination
Prefix
Address Prefix
Range
Port
Range ALLOW VNET OUTBOUND 65000
Allow
VIRTUAL_NETWORK *
VIRTUAL_NETWORK *
ALLOW INTERNET
65001
Allow
*
*
INTERNET
*
OUTBOUND DENY ALL OUTBOUND
65500
Deny
*
*
*
*
* *
*
4. Create a security rule allowing access from the Internet to port 80. Get-AzureNetworkSecurityGroup -Name "NSG-FrontEnd" ` | Set-AzureNetworkSecurityRule -Name web-rule ` -Action Allow -Protocol TCP -Type Inbound -Priority 200 ` -SourceAddressPrefix Internet -SourcePortRange '*' ` -DestinationAddressPrefix '*' -DestinationPortRange '80'
Expected output:
Name Location Label Rules
: NSG-FrontEnd : Central US : Front end subnet NSG : Type: Inbound
Destination
Name Protocol
Priority Action
Source Address Source Port
Destination
Prefix
Range
Address Prefix
Port
Range rdp-rule
100
Allow
INTERNET
*
*
3389
web-rule
200
Allow
INTERNET
*
*
80
ALLOW VNET INBOUND
65000
Allow
VIRTUAL_NETWORK *
VIRTUAL_NETWORK *
ALLOW AZURE LOAD
65001
Allow
AZURE_LOADBALAN *
*
*
BALANCER INBOUND DENY ALL INBOUND
65500
Deny
CER *
*
*
TCP TCP * * *
*
Type: Outbound
Destination
Name Protocol
Priority Action
Source Address Source Port
Destination
Prefix
Address Prefix
Range
Port
Range ALLOW VNET OUTBOUND 65000
Allow
VIRTUAL_NETWORK *
VIRTUAL_NETWORK *
ALLOW INTERNET
65001
Allow
*
*
INTERNET
*
OUTBOUND DENY ALL OUTBOUND
65500
Deny
*
*
*
*
* *
*
How to create the NSG for the back end subnet 1. Create a network security group named NSG-BackEnd. New-AzureNetworkSecurityGroup -Name "NSG-BackEnd" -Location uswest ` -Label "Back end subnet NSG"
Expected output: Name
Location
NSG-BackEnd West US
Label Back end subnet NSG
2. Create a security rule allowing access from the front end subnet to port 1433 (default port used by SQL Server).
Get-AzureNetworkSecurityGroup -Name "NSG-FrontEnd" ` | Set-AzureNetworkSecurityRule -Name rdp-rule ` -Action Allow -Protocol TCP -Type Inbound -Priority 100 ` -SourceAddressPrefix 192.168.1.0/24 -SourcePortRange '*' ` -DestinationAddressPrefix '*' -DestinationPortRange '1433'
Expected output: Name Location Label Rules
: NSG-BackEnd : Central US : Back end subnet NSG : Type: Inbound
Destination
Name Protocol
Priority Action
Source Address Source Port
Destination
Prefix
Address Prefix
Port
1433
Range
Range fe-rule
100
Allow
192.168.1.0/24 *
*
ALLOW VNET INBOUND
65000
Allow
VIRTUAL_NETWORK *
VIRTUAL_NETWORK *
ALLOW AZURE LOAD
65001
Allow
AZURE_LOADBALAN *
*
*
BALANCER INBOUND DENY ALL INBOUND
65500
Deny
CER *
*
*
TCP * * *
* Type: Outbound
Destination
Name Protocol
Priority Action
Source Address Source Port
Destination
Prefix
Address Prefix
Range
Port
Range ALLOW VNET OUTBOUND 65000
Allow
VIRTUAL_NETWORK *
VIRTUAL_NETWORK *
ALLOW INTERNET
65001
Allow
*
*
INTERNET
*
OUTBOUND DENY ALL OUTBOUND
65500
Deny
*
*
*
*
* *
*
3. Create a security rule blocking access from the subnet to the Internet. Get-AzureNetworkSecurityGroup -Name "NSG-BackEnd" ` | Set-AzureNetworkSecurityRule -Name block-internet ` -Action Deny -Protocol '*' -Type Outbound -Priority 200 ` -SourceAddressPrefix '*' -SourcePortRange '*' ` -DestinationAddressPrefix Internet -DestinationPortRange '*'
Expected output:
Name Location Label Rules
: NSG-BackEnd : Central US : Back end subnet NSG : Type: Inbound
Destination
Name Protocol
Priority Action
Source Address Source Port
Destination
Prefix
Address Prefix
Port
1433
Range
Range fe-rule
100
Allow
192.168.1.0/24 *
*
ALLOW VNET INBOUND
65000
Allow
VIRTUAL_NETWORK *
VIRTUAL_NETWORK *
ALLOW AZURE LOAD
65001
Allow
AZURE_LOADBALAN *
*
*
BALANCER INBOUND DENY ALL INBOUND
65500
Deny
CER *
*
*
TCP * * *
* Type: Outbound
Destination
Name Protocol
Priority Action
Source Address Source Port
Destination
Prefix
Range
Address Prefix
Port
Deny
*
*
INTERNET
*
ALLOW VNET OUTBOUND 65000
Allow
VIRTUAL_NETWORK *
VIRTUAL_NETWORK *
ALLOW INTERNET
65001
Allow
*
*
INTERNET
*
OUTBOUND DENY ALL OUTBOUND
65500
Deny
*
*
*
*
Range block-internet
200
* * *
*
Create a custom virtual machine running Windows using the classic deployment model 6/1/2017 • 3 min to read • Edit Online
IMPORTANT Azure has two different deployment models for creating and working with resources: Resource Manager and Classic. This article covers using the Classic deployment model. Microsoft recommends that most new deployments use the Resource Manager model.
A custom virtual machine simply means a virtual machine that you create using a Featured app from the Marketplace because it does much of the work for you. Yet, you can still make configuration choices that include the following items: Connecting the virtual machine to a virtual network. Installing the Azure Virtual Machine Agent and Azure Virtual Machine Extensions, such as for antimalware. Adding the virtual machine to existing cloud services. Adding the virtual machine to an existing Storage account. Adding the virtual machine to an availability set. IMPORTANT If you want your virtual machine to use a virtual network, make sure that you specify the virtual network when you create the virtual machine. Two benefits of using a virtual network are connecting directly to the virtual machine and to set up cross-premises connections. A virtual machine can be configured to join a virtual network only when you create the virtual machine. For details on virtual networks, see Azure Virtual Network overview.
To create the virtual machine 1. Sign in to the Azure portal. 2. Starting in the upper left, click New > Compute > Windows Server 2016 Datacenter.
3. On the Windows Server 2016 Datacenter, select the Classic deployment model. Click Create.
1. Basics blade The Basics blade requests administrative information for the virtual machine. 1. Enter a Name for the virtual machine. In the example, HeroVM is the name of the virtual machine. The name must be 1-15 characters long and it cannot contain special characters. 2. Enter a User name and a strong Password that are used to create a local account on the VM. The local account is used to sign in to and manage the VM. In the example, azureuser is the user name. The password must be 8-123 characters long and meet three out of the four following complexity requirements: one lower case character, one upper case character, one number, and one special character. See more about username and password requirements. 3. The Subscription is optional. One common setting is "Pay-As-You-Go". 4. Select an existing Resource group or type the name for a new one. In the example, HeroVMRG is the name of the resource group. 5. Select an Azure datacenter Location where you want the VM to run. In the example, East US is the location. 6. When you are done, click Next to continue to the next blade.
2. Size blade The Size blade identifies the configuration details of the VM, and lists various choices that include OS, number of processors, disk storage type, and estimated monthly usage costs. Choose a VM size, and then click Select to continue. In this example, DS1_V2 Standard is the VM size.
3. Settings blade The Settings blade requests storage and network options. You can accept the default settings. Azure creates appropriate entries where necessary. If you selected a virtual machine size that supports it, you can try Azure Premium Storage by selecting Premium (SSD) in Disk type. When you're done making changes, click OK.
4. Summary blade The Summary blade lists the settings specified in the previous blades. Click OK when you're ready to make the image.
After the virtual machine is created, the portal lists the new virtual machine under All resources, and displays a tile of the virtual machine on the dashboard. The corresponding cloud service and storage account also are created and listed. Both the virtual machine and cloud service are started automatically and their status is listed as Running.
Next steps You can also create a custom virtual machine running Linux.
Create a Windows virtual machine with PowerShell and the classic deployment model 6/1/2017 • 9 min to read • Edit Online
IMPORTANT Azure has two different deployment models for creating and working with resources: Resource Manager and Classic. This article covers using the Classic deployment model. Microsoft recommends that most new deployments use the Resource Manager model. Learn how to perform these steps using the Resource Manager model.
These steps show you how to customize a set of Azure PowerShell commands that create and preconfigure a Windows-based Azure virtual machine by using a building block approach. You can use this process to quickly create a command set for a new Windows-based virtual machine and expand an existing deployment or to create multiple command sets that quickly build out a custom dev/test or IT pro environment. These steps follow a fill-in-the-blanks approach for creating Azure PowerShell command sets. This approach can be useful if you are new to PowerShell or you just want to know what values to specify for successful configuration. Advanced PowerShell users can take the commands and substitute their own values for the variables (the lines beginning with "$"). If you haven't done so already, use the instructions in How to install and configure Azure PowerShell to install Azure PowerShell on your local computer. Then, open a Windows PowerShell command prompt.
Step 1: Add your account 1. 2. 3. 4.
At the PowerShell prompt, type Add-AzureAccount and click Enter. Type in the email address associated with your Azure subscription and click Continue. Type in the password for your account. Click Sign in.
Step 2: Set your subscription and storage account Set your Azure subscription and storage account by running these commands at the Windows PowerShell command prompt. Replace everything within the quotes, including the < and > characters, with the correct names. $subscr="" $staccount="" Select-AzureSubscription -SubscriptionName $subscr –Current Set-AzureSubscription -SubscriptionName $subscr -CurrentStorageAccountName $staccount
You can get the correct subscription name from the SubscriptionName property of the output of the GetAzureSubscription command. You can get the correct storage account name from the Label property of the output of the Get-AzureStorageAccount command after you run the Select-AzureSubscription command.
Step 3: Determine the ImageFamily Next, you need to determine the ImageFamily or Label value for the specific image corresponding to the Azure
virtual machine you want to create. You can get the list of available ImageFamily values with this command. Get-AzureVMImage | select ImageFamily -Unique
Here are some examples of ImageFamily values for Windows-based computers: Windows Server 2012 R2 Datacenter Windows Server 2008 R2 SP1 Windows Server 2016 Technical Preview 4 SQL Server 2012 SP1 Enterprise on Windows Server 2012 If you find the image you are looking for, open a fresh instance of the text editor of your choice or the PowerShell Integrated Scripting Environment (ISE). Copy the following into the new text file or the PowerShell ISE, substituting the ImageFamily value. $family="" $image=Get-AzureVMImage | where { $_.ImageFamily -eq $family } | sort PublishedDate -Descending | select ExpandProperty ImageName -First 1
In some cases, the image name is in the Label property instead of the ImageFamily value. If you didn't find the image that you are looking for using the ImageFamily property, list the images by their Label property with this command. Get-AzureVMImage | select Label -Unique
If you find the right image with this command, open a fresh instance of the text editor of your choice or the PowerShell ISE. Copy the following into the new text file or the PowerShell ISE, substituting the Label value. $label="
