Setting Up An EMS Lab in ARM (Azure Resource Manager) Step-By-Step – Part 1
Quick links to the other parts of the post:-
I’ve always wanted to do this and the thought of not needing any hardware to run my virtual machines to achieve what I want is such a cool idea. Now is the time I have the chance to do it and here’s the sharing of my experience performing it in the new Azure portal (vs the classic portal) known as the Azure Resource Manager (ARM). Hope you enjoy it.
First we would need a Resource Group. A Resource Group is defined as a container that holds related resources for an application. The resource group could include all of the resources for an application, or only those resources that are logically grouped together. You can decide how you want to allocate resources to resource groups based on what makes the most sense for your organization. Read more about Resource Groups here.
So, go ahead and create a new Resource Group. Click on Resource groups to open up the blade, then click Add.
Give your Resource Group a name. I like to have a naming conventions for resource groups with a prefix of “RG-“. Choose your subscription you want it to be created in and the location where you want the Resource Group to be created.
The Resource Group is created. Click on the newly created resource group to open up the blade where you can see information about it.
Secondly, we need a new Storage Account. An Azure storage account provides a unique namespace to store and access your Azure Storage data objects. All objects in a storage account are billed together as a group. By default, the data in your account is available only to you, the account owner.
Click on Storage Accounts, then click Add.
Storage Account names must be unique and only supports lowercase characters and numbers, so choose wisely :). I like to use a naming convention with a prefix of “st”. Use the locally-redundant storage (LRS) with Standard performance to save on cost/credits. Make sure you select the Resource Group that you just created in the previous step. Click Create to begin creating the Storage Account. Read more about Azure Storage Accounts here.
- Name: stxxx
- Deployment model: Resource manager
- Account kind: General purpose
- Performance: Standard
- Replication: Locally-redundant storage (LRS)
- Subscription: <choose one>
- Resource group: <choose>
- Location: <choose one>
The Storage Account is created. Click on the newly created Storage Account to view the information about the Storage Account.
Next we need a new Virtual Network. An Azure virtual network (VNet) is a representation of your own network in the cloud. It is a logical isolation of the Azure cloud dedicated to your subscription. You can fully control the IP address blocks, DNS settings, security policies, and route tables within this network. You can also further segment your VNet into subnets and launch Azure IaaS virtual machines (VMs) and/or Cloud services (PaaS role instances). Additionally, you can connect the virtual network to your on-premises network using one of the connectivity options available in Azure. In essence, you can expand your network to Azure, with complete control on IP address blocks with the benefit of enterprise scale Azure provides. Read more on Virtual Networks here.
Click on Virtual networks, then click Add.
Enter all the details to create a new Virtual Network then click Create. I like to use the prefix of “VNET-” to indicate a virtual network object. Remember to select the Resource Group that you just created.
The Virtual Network is created. Click on the newly created Virtual Network to view the information about the Virtual Network.
Now we need a new Network Security Group. Network security group (NSG) contains a list of Access Control List (ACL) rules that allow or deny network traffic to your VM instances in a Virtual Network. NSGs can be associated with either subnets or individual VM instances within that subnet. When a NSG is associated with a subnet, the ACL rules apply to all the VM instances in that subnet. In addition, traffic to an individual VM can be restricted further by associating a NSG directly to that VM. Read more about Network Security Group here.
Click on Network Security Groups, then click Add.
Enter all the details to create a new Network Security Group then click Create. I like to use the prefix of “NSG-” to indicate a Network Security Group object. Remember to select the Resource Group that you just created.
The Network Security Group is now created. Click on the newly created Network Security Group to view the information about the Network Security Group.
Now that you’ve got a net Network Security Group created, we would need to configure it so that it will allow Remote Desktop to get to and from our virtual machines. Click on the Inbound security rules on the Settings blade then click Add.
Here’s what you would want to configure in your inbound rule to allow Remote Desktop into this Network Security Group. Feel free to change the name and priority to suit your situation and obviously port 3389 is the RDP port number.
- Name: AllowRDPInbound
- Priority: 100
- Source: Any
- Protocol: Any
- Source port range: *
- Destination: Any
- Destination port range: 3389
- Action: Allow
Now for the outbound rule. Similarly, now click on Outbound security rules and then click Add.
Now that we’ve got the Network Security Group created and configured to allow at least RDP traffic to go through it, we now need to associate it. A Network Security Group can either be associated to a network interface or to a subnet. In our case to keep it really simple we’re associating it to a subnet.
Click on Subnets and then click Associate.
Click on Virtual network then choose the Virtual Network we’ve just created for this lab.
Click Subnet then choose the subnet that is associated to the Virtual Network of your lab. When you’re done, click OK.
We’ll continue the rest of the lab setup in Part 2 of this posting.