Getting Around Blocked Ports

Regularly, I find myself in a location that blocks ports to the outside world. In many of those moments, I can’t use Remote Desktop (RDP) sessions to connect to Virtual Machines hosted on Azure. The strategy expressed in this post is one of many possible solutions that also applies to Linux and SSH sessions.

The Strategy

• Using a Load Balancer and NAT rules to map port 443 to the RDP (3389) port for a Jumpbox Virtual Machine (VM)
• Using the Jumpbox to RDP into VMs deployed to the Azure Virtual Network.
  

Deploying Nano Server to Azure

Based on the current builds, compared to Server, Nano Server has 93 percent lower VHD size, 92 percent fewer critical bulletins and 80 percent fewer reboots!

I’ve been curious about Nano Server for a while now. And I recently noticed that it was available on Microsoft Azure. This post is definitely from a developers point-of-view. It goes through the steps required to create a functional Nano Server Virtual Machines (VM) on Microsoft Azure.

Nano Server is ideal for many scenarios:

• As a “compute” host for Hyper-V virtual machines, either in clusters or not
• As a storage host for Scale-Out File Server.
• As a DNS server
• As a web server running Internet Information Services (IIS)
• As a host for applications that are developed using cloud application patterns and run in a container or virtual machine guest operating system.

The Adventure

Nano Server is a remotely administered server operating system (OS). Wait. Let me repeat this because it’s important… Nano Server is a remotely administered server operating system (OS). Developers, Nano Server is a server OS optimized for clouds and data centers. It’s designed to take up far less disk space, to setup significantly faster, and to require far fewer restarts than Windows Server. So why does this matter? Well it means more resources, more availability and stability for our Apps. And it also means that it’s time to learn new skills, because there is no local logon capability at all, nor does it support Terminal Services. However, we have a wide variety of options for managing Nano Server remotely, including Windows PowerShell, Windows Management Instrumentation (WMI), Windows Remote Management, and Emergency Management Services (EMS).

Using ARM to Deploy Global Solutions

Imagine deploying your secure load balanced solution to three datacenters, putting in place a worldwide load balancer and doing so in roughly 24 minutes. Did I mention that this deployment is predictable and repeatable?

Good, now that I’ve got your attention, it’s time to dive in!

Building on my previous post about managing compute resources on Azure I decided to modify the Azure Resource Manager(ARM) template to deploy a real-world environment to three datacenters (Yes I know, the diagrams shows two locations, but as I built the demo, I got greedy…). Using Azure Traffic Manager we are able positively affect a users experience by directing them to the closest datacenter.

Its important to note that ARM does not support nested copy operation. This means that we have to use a different strategy to deploy identical environments in multiple Azure regions. After a bit of research it became apparent that I had to use nested deployments. This technique requires us to break our template into multiple files. The parent template in this demo is the azuredeploy-multi-geo.json file. It contains the full list of parameters, a nested deployment that deploys instances of our environment to multiple Azure regions, and a Traffic Manager definition. The azuredeploy.json template file was refactored from the template used in my previous blog post. It contains networking, storage and Virtual Machine definitions.

Share this:

A little while ago, I wrote about building, using and destroying environments on Azure. At first, what I proposed may have seemed like overkill, so I took this as a challenge and built this short demo project to demonstrate why I favor destroying environments to shutting them down.

Using Azure PowerShell 1.0 & ARM

Recently the Azure team released a new version of Microsoft Azure PowerShell. They finally broke through v1.0, and that comes with a few breaking changes. But don’t worry, it’s for the best!

This blog post is all about deploying a Windows 10 Visual Studio Virtual Machine to a secured Virtual Network on Microsoft Azure.

Deploying an ARM Template Using PowerShell

Lost in Translation – Azure Networking

In today’s highly connected world, many professionals use Cisco’s terminology to discuss networking. Using the wrong terms can lead to lengthy, confusing arguments. The goal of this post, is to help those of us who don’t speak the language, to communicate effectively with others about Azure Networking.

I’ve been dabbling in the IT Pro space for a few months now, and it’s been a challenge to discuss Azure Networking. Coming from a development background, my reference to networking was Azure. That definitely made it difficult, because I spoke about Virtual Networks, Subnets and Network Security Groups. To help me sort things out, I asked a colleague of mine to identify the equivalencies between Cisco and Azure Networking terminology.

Let’s dive in!

Provisioning a Virtual Machine on Azure

This post will help you setup a CentOS 7.1 Virtual Machine on Azure using Azure Resource Manager (ARM) and PowerShell.

Testing Visual Studio on Azure

A few months ago I wrote about my Dev and Test adventure, where I used the Azure Portal to create my Virtual Machine. Since then, Microsoft has released significant additions to the Azure Resource Manager (ARM). This post is all about provisioning a Visual Studio Virtual Machine to your MSDN Azure Subscription using ARM.

Share this:

While I was playing around with the Azure Resource Manager Copy Operation, I started thinking about what I could do with it. The first wild idea that popped into my head was, to use it to deploy multi-geo environments from a single ARM Template.

Alright, some of you might think that it’s not such great idea, and I can appreciate that. But I’m just too curious, so let’s give this a chance.

Deploying 20 CentOS VMs in 4 Minutes!

I recently started to toy around with scenarios that required me to deploy multiple duplicates of the same CentOS Virtual Machine configuration. Working on this scenario got me curious. So I decided to build a template that would allow me to deploy 20 CentOS Virtual Machines each with one 1TB data disk and one public IP addresses.

To my surprise, deploying these 20 Standard A1 CentOS Virtual Machines on Microsoft Azure took 4 minutes!

Building the ARM Template

Let’s start by taking a CentOS ARM Template from a previous post. It will be our starting point for this exercise. Now, let’s removed the extra data disk and removed the Custom Script for Linux Virtual Machine Extension.

To duplicate a resource, we must use the copy operation. It enables us to use an index number or to iterate through an array of values that can be used when deploying a resource.

"copy": {
          "name": "nodeCopy",
          "count": "[parameters('vmCount')]"
}

In this specific scenario, we want all our Virtual Machines to belong to the same Virtual Network and Subnet. Therefore, we need to duplicate each Virtual Machine, their Network Interface Cards (NIC) and their Public IP Addresses.

The following template, demonstrates the use of copyIndex() and concat(), to generate predictable identifiers for each copy.