connected to an Azure virtual network. That type of peering is also available with
ExpressRoute, but so are other kinds. Public peering with ExpressRoute enables
nearly all Azure services to be accessed via ExpressRoute, which would otherwise be
accessed over Internet endpoints. Consider services such as Azure Storage, Azure
Backup, and Azure SQL Database as just a few examples of useful services that can be
used in new ways when not accessed over the Internet and instead accessed over a
secure, low-latency connection. There is also Microsoft peering, which connects to
Office 365 and CRM Online services via the connection, but this is only recommended
in specialized scenarios.
For organizations using Azure for production tasks, ExpressRoute is highly
recommended over site-to-site VPN. However, organizations can still have site-to-site
VPN as a fallback connectivity option, as it can coexist with ExpressRoute.
A point-to-site VPN capability is also available to give specific machines connectivity
to Microsoft Azure. It leverages a special client component that is downloaded from
the Microsoft Azure management portal, and the clients connecting using the VPN
client component receive an IP address from a pool defined as part of the Microsoft
Azure point-to-site VPN configuration. If you need this kind of point-to-site VPN, it is
available as an option, and Microsoft has plenty of documentation. The primary
documents are available at https://azure.microsoft .com/en-
us/documentation/articles/vpn-gateway-howto-point-to-site-rm-ps/.
Managing with PowerShell
I went into detail on the creation of virtual machines using the Microsoft Azure web-
based management portal. Virtual machines can also be created using PowerShell and
JSON templates. Where possible, avoid the portal, because you cannot automate
provisioning by using the portal; it’s thus not repeatable. It’s great to look around and
experiment with Azure, but it should not be the tool used for production provisioning.
Choosing between JSON and PowerShell is tricky. JSON has the benefit of being
immutable; I can run a template, and if there is a problem, I can fix the problem and
rerun the template, and only what is different or missing will be created. This is not
the case with standard PowerShell. If I have a PowerShell script creating many
resources and it crashes halfway through, I cannot simply rerun the script, because it
will err, as many resources would already exist. However, for administrators who are
familiar with PowerShell, it will probably be preferable over learning a completely new
way of defining resources. If you want to look at JSON templates, I recommend
looking at the GitHub repository at https://github.com/Azure/azure-quickstart-
templates, which has a whole series of templates starting with simple ones (prefixed
with 101 ) to more complicated, multitier deployments. While the JSON templates are
verbose, they are also fairly simple, consisting of blocks of input parameters,
constants used throughout the template (although they are called variables), and then
the actual definition of resources to be created along with dependencies between
them. A good start is the simple Windows VM at https://github.com/Azure/azure-
quickstart-templates/blob/master/ 101 - vm-simple-windows/azuredeploy.json. As an