Latest posts by Paul Schnackenburg (see all)
- ManageEngine Desktop Central: Unified endpoint management for Windows, Linux, and Mac - Wed, Sep 18 2019
- Nakivo Backup & Replication 9.0 for Windows Server 2019 - Wed, Aug 28 2019
- SolarWinds Security Event Manager: Threat detection and remediation - Thu, Aug 8 2019
Create a virtual network ^
Most of my students head straight to the Virtual Machines tab when they first open an Azure trial. They don’t realize that, although this method will work, it’ll be a lot less flexible because many of the network settings are defined for you without the opportunity to set them yourself. Once you’ve set up a virtual network (and spun up a VM connected to it), there are several settings that can’t be changed.
To create a virtual network, you’ll need to know the region and affinity group that your network is going to be associated with, the address space that you want to create, DNS servers (this is optional; see below), and—if you’re going to connect to your on-premises network—VPN device info and the public IP address.
The way I describe Azure networks is that it’s another branch office in your WAN. Before you start plugging in servers and clients, you make sure that the office is wired and has switches in place and that the router and WAN link are active.
Virtual network settings are stored in a netcfg file. Presently, the new DevOps portal (portal.azure.com) doesn’t let you create virtual networks, although you can see existing networks.
Creating a physical network is a lot more work than clicking a few buttons in the GUI and creating a Virtual Network.
In the GUI, click the Networks tab, and then click New and Custom Create. Select a region and name the network. On the next tab, you can define a DNS server and specify whether you want to use Point to Site (P2S) and/or Site to Site (S2S) VPN functionality. If you select P2S, you must then define the address space for clients. If you also select S2S, you can optionally go for ExpressRoute; you also have to define which local network (in your on-premises data center) to which this virtual network will connect. We’ll cover S2S and ExpressRoute in the next part in this series. Here, we’ll simply select P2S and accept the default address spaces.
If you want to use PowerShell, there isn’t actually a Create-VMNetwork cmdlet. Instead, you have to edit a NetworkConfig.xml file and then import those settings using Set-AzureVNetConfig. The easiest way to get a sample file is to create a network in the portal and then export that into a file (middle button at the bottom in the Networks pane) or use Get-AzureVNetConfig with –ExportToFile.
First, grab your current virtual network settings with this cmdlet and save them.
Once you’ve edited the file, you can “upload” your network(s) to Azure using:
Set-AzureVNetConfig <path to your network config file>
Uploading your new network settings takes a few seconds, but the extra validation is a good safety net.
Don’t worry about fat fingering something in the config file. Validation is extensive as you run this, and you’ll be informed if something needs fixing. Note that this will update any existing networks you already have in place.
To DNS or not to DNS ^
You can do DNS in Azure in two ways. If you can get by with the functionality that the built-in Azure DNS service provides, this is the easiest way to go. However, you’ll need your own DNS server(s) if you require any of the following:
- You need on-premises computers to be able to “find” Azure VMs, or vice versa.
- You have several virtual networks (in different regions, say) and you want VMs to find each other across the networks.
- You intend to use an Active Directory Domain Controller in the cloud and the built-in Azure DNS doesn’t support the required records.
For more information on the two options, see here.
Fixed IP address in Azure? ^
When you create a new VM in a virtual network, Azure assigns it a “fixed” IP. You can predict what the IP address for each VM will be; .1 to .3 is reserved, so the first VM will get .4 in your particular address space. If you restart the VM from within the VM, it will keep its IP address (unlike normal DHCP clients), but if you shut a VM down through PowerShell or in the GUI, it’s de-provisioned and might get a different IP address when you restart it. For some VMs, this might not be a problem; if you have DNS, domain controllers, or similar servers, you can use the Set-AzureStaticVNetIP cmdlet to permanently set their address. This can be done for both new VMs and existing ones. For a new one, this is how to do it:
$VM = New-AzureVMConfig -Name Sysops1 -InstanceSize Small -ImageName "3a50f22b388a4ff7ab41029918570fa6__Windows-Server-2012-Essentials-20140715-enus" -HostCaching ReadWrite -DiskLabel "OS" -MediaLocation "http://<name of storage>.blob.core.windows.net/vhds/sysops1.vhd" |
Add-AzureProvisioningConfig -windows -AdminUsername sysadmin -Password Password1 |
Set-AzureStaticVNetIP -IPAddress 10.0.1.28 |
Set-AzureSubnet -SubnetNames subnet-1
New-AzureVM -VM $VM -ServiceName expertitdc -VNetName sysopsvm_net_1
This is a fair bit of code, so let’s break it down. First, we set up a configuration container for the VM, defining items such as the VM size and the name of your BLOB storage account where the VHD will be housed. You also need to provide the image (the VM “template”); to find out which ones are available (as they change regularly), use Get-AzureVMImage.
Then, we use Add-AzureProvisioningConfig to add the information that this is a Windows VM and set the local password; you could also define other information, such as domain name to join and domain username and password. Finally, we define our fixed IP address for the VM, define which subnet to connect the VM to, and create the VM with New-AzureVM.
You can also update an existing VM; see here.
Next time, we’ll look at options for connecting your on-premises networks (and developer laptops) to your shiny new virtual network.