Tag Archives: azure vm

Step-by-Step Guide to protect Azure VM using Azure Backup

Azure Backup is capable of replacing typical on-premises backup solutions. It is cloud-based, secure, reliable solution. It has four components which can use to backup different types of data.

Component

Protected data

Can use with On-premises?

Can use with Azure?

Azure Backup (MARS) agent

Files, Folders, System State

Yes

Yes

System Center DPM

Files, Folders, Volumes,

VMs, Applications, Workloads, System State

Yes

Yes

Azure Backup Server

Files, Folders, Volumes,

VMs, Applications, Workloads, System State

Yes

Yes

Azure IaaS VM Backup

VMs, All disks (using PowerShell)

No

Yes

More details about azure backup and components limitations can be find on https://docs.microsoft.com/en-us/azure/backup/backup-introduction-to-azure-backup 

In this article we are going to look in to Azure VM backup (Azure IaaS VM Backup). 

How Azure VM Backup works? 

Azure VM backup doesn’t need any special agent installed in VM. It also does not need to have any additional components (backup server) install either to enable backup. When very first backup job is triggered, it installs backup extension inside the VM. If its Windows VM, it installs VMSnapshot extension and if its Linux VM, it installs VMSnapshotLinux extension. VM must be in running state in order to install extension. After extension in place, it takes point-in-time snapshot of the VM. If VM is not running during backup window, it takes snapshot of VM storage. If its windows VM, backup service uses Volume Shadow Copy Service (VSS) to get consistence snapshot of VM disk. If its Linux VM, users can create custom scripts to run before and after backup job to keep application consistency. Once snapshot is taken it will transfer to the backup vault. Service can identify the recent changes and only transfer the block of data which changed from last backup. Once the data transfer completes snapshot will removed and recovery point will be created. 

vmbackup-architecture

Image Source: https://docs.microsoft.com/en-us/azure/backup/media/backup-azure-vms-introduction/vmbackup-architecture.png 

Performance of backup depends on,

1) Storage account limitations 

2) Number of disks in VM

3) Backup Schedule – if all jobs running in same time it can create traffic jam

According to Microsoft following are recommended when you use Azure backup for Azure VMs. Reference: https://docs.microsoft.com/en-us/azure/backup/backup-azure-vms-introduction 

1) Do not schedule more than 40 VMs to backup same time.

2) Schedule VMs backup when minimum IOPs been used in your environment (In relevant storage accounts). 

3) Better not to back up more than 20 disks in single storage account. If you have more than 20 disks in single storage account spread those VMs across the multiple policies to maintain required IOPS. 

4) Do not restore a VM running on Premium storage to same storage account. Also try to avoid restore while backup process is running on same storage account.

5) For Premium VM backup, ensure that storage account that hosts premium disks has at least 50% free space for staging snapshot for a successful backup.

6) Linux VM needs python 2.7 enabled for backup.

Next step is to see this in action.

1) Log in to Azure Portal as Global Administrator

2) First step is to create Azure Recovery Service Vault. In order to do that, go to All Services and click on Recovery Service vaults under storage section. 

bk1

3) Then click on Add in new window

bk2

4) It will open up wizard and there provide vault name, subscription, resource group and location. Once done, click on Create.

bk3

5) Now we have vault created, next step is to create backup policy. To do that click on vault we just created from the Recovery service vault window.

bk4

6) Then click on Backup Policies 

bk5

7) There is default policy from Azure VM backup. It backup VMs daily and keep it for 30 days.

bk6

8) I am going to create new policy to do backup every day at 01:00 am and keep it for 7 days. To do that click on add option in policy window. 

bk7

9) Then select the policy type. for VMs, it should be Azure Virtual Machine

bk8

10) In next window we can define time and retention period of data. Once done with the details click on Create

bk9

11) Next step of the configuration is to enable backup. In order to do that, go to the VM you like to backup. Then click on the option Backup 

bk10

12) Then in new window select the vault and policy we created before and then click on enable backup

bk11

13) Once it is done we can run backup by going in to same backup window. If you like to take ad-hoc backup, click on Backup Now

bk12

14) We can see the progress of the backup job by clicking View All Jobs

bk13

bk14

15) Once backup jobs completed we can see the status of it in same backup window.

bk15

16) To test the restore I installed Acrobat Reader in this server and created test folder in desktop. 

bk16

17) Now I am going to do a restore to an earlier day. To do that go to VM backup page, then click on Restore VM

bk17

18) In next window it asks which backup to restore. I am selecting back up from 3 days.

bk18

19) In next window it allows me to restore it as new VM or as disk. In here I am going to restore it as new VM

bk19

20) Once selection is done click on Restore to begin the process.

21) We also can check the status of the job using backup job window.

bk20

22) Once restore completed, I can see a new VM. 

bk21

23) Once log in to the VM I can’t see the folder and application I installed, as expected. 

bk22

This marks the end of this blog post. If you have any questions feel free to contact me on rebeladm@live.com also follow me on twitter @rebeladm to get updates about new blog posts.

Azure virtual machine scale sets – part 02 – Deploy Application to scale set

In my previous post Azure virtual machine scale sets – part 01, we learned what is VM scale set and how we can create a scale set in Azure. if you not read it yet please go through it before we start on this post as reset of the steps in this post depend on it http://www.rebeladmin.com/2018/04/azure-virtual-machine-scale-sets-part-01/ 

In this post we are going to deploy a sample application to scale set. In my previous post I have created a new scale set using,

New-AzureRmVmss `

  -ResourceGroupName "rebelResourceGroup" `

  -Location "canadacentral" `

  -VMScaleSetName "rebelScaleSet" `

  -VirtualNetworkName "rebelVnet" `

  -SubnetName "rebelSubnet" `

  -PublicIpAddressName "rebelPublicIPAddress" `

  -LoadBalancerName "rebelLoadBalancer" `

  -BackendPort "80" `

  -VmSize "Standard_DS3_v2" `

  -ImageName "Win2012Datacenter" `

  -InstanceCount "4" `

  -UpgradePolicy "Automatic"

In above it created an Azure Load balancer and TCP port 80 been load balanced among 4 instances. Under Azure Load Balancer | Inbound NAT rules it does have default rules for port 3389 and 5985. Those ports are mapped to custom TCP ports in order to give external access. 

scaleapp1

As an example, in above sample, I can RDP to instance0 using 52.237.8.186:50000. Likewise, we can connect to each instance and install apps if need. instead of that we can use centralized remote deployment, so the configuration is same across the instance. 

In my config I didn’t use static ip address. You can find public ip address by running following azure PowerShell command,

Get-AzureRmPublicIpAddress -ResourceGroupName rebelResourceGroup | Select IpAddress

scaleapp2

In order to push application, first need to prepare app config. in my demo I got a file in GitHub repository. 

$customConfig = @{

  "fileUris" = (,"https://raw.githubusercontent.com/rebeladm/rebeladm/master/simplewebapp.ps1");

  "commandToExecute" = "powershell -ExecutionPolicy Unrestricted -File simplewebapp.ps1"

}

My config is very simple one. In PowerShell script I have following,

Add-WindowsFeature Web-Server

Set-Content -Path "C:\inetpub\wwwroot\Default.htm" -Value "Test webapp running on host $($env:computername) !"

It will install IIS and then create HTML file which will print text with the instance name. 

scaleapp3

As next step lets go and retrieve info about scale set,

$vmss = Get-AzureRmVmss `

          -ResourceGroupName "rebelResourceGroup" `

          -VMScaleSetName "rebelScaleSet"

scaleapp4

After that, lets create custom script extension

$vmss = Add-AzureRmVmssExtension `

  -VirtualMachineScaleSet $scaleconfig `

  -Name "customScript" `

  -Publisher "Microsoft.Compute" `

  -Type "CustomScriptExtension" `

  -TypeHandlerVersion 1.8 `

  -Setting $customConfig

In above,

 –Publisher specifies the name of the extension publisher. This can find using Get-AzureRmVMImagePublisher 

 –Type specify the extension type. we can use Get-AzureRmVMExtensionImageType find the extension type. 

TypeHandlerVersion specify the extension version. It can view using Get-AzureRmVMExtensionImage.

scaleapp5

Next step of the configuration is to update scale set with the custom extension,

Update-AzureRmVmss `

  -ResourceGroupName "rebelResourceGroup" `

  -Name "rebelScaleSet" `

  -VirtualMachineScaleSet $vmss

scaleapp6

Now it is time to do testing. Let’s go to public IP address and see if it’s got the app we submit. 

As I refresh we can see the instance number get updated. That means script is successfully running on scale set as expected. 

scaleapp7

scaleapp8

scaleapp9

This marks the end of this blog post. If you have any questions feel free to contact me on rebeladm@live.com also follow me on twitter @rebeladm to get updates about new blog posts.  

Azure Virtual Machine Scale Sets – Part 01 – What is it and How to set it up?

There are many different solutions available to load balance applications. It can be based on separate hardware appliances, virtual appliances or system inbuilt method such as NLB (Network Load Balancer). However, there are few common challenges on these environments. 

If its third-party solution, additional cost involves for licenses, configuration and maintenance 

Applications or services not always use all of the allocated resources. It may depend on demand and time. Since its fixed number of instance, infrastructure resource will be wasted in non-peak time. if its cloud service, it going to waste money!

When the number of server instances increase, it makes it harder to manage systems. Too many manual tasks!

Azure virtual machine scale sets answers all above challenges. It can automatically increase and decreases number of vm instances running based on demand or schedule. No extra virtual appliances or licenses involves. It also allows to centrally manage, configure large number of instances. Following points are recognized as key benefits of Azure virtual machine scale sets.

It supports Azure load balancer (Layer-4) and Azure Application Gateway (Layer-7) traffic distribution.

It allows to maintain same VM configuration across the instance including VM size, Network, Disk, OS image, Application installs. 

Using Azure Availability Zones, if required we can configure to distribute VM instances in scale set to different datacenters. It adds additional availability. 

It can automatically increase and decrease number of vm instances running based on application demand. It saves money!

It can grow up to 1000 vm instances, if its own custom images, it supports up to 300 vm instances. 

It supports Azure Managed Disks and Premium Storage. 

Let’s see how we can setup Azure virtual machine scale set. In my demo I am going to use Azure PowerShell. 

1) Log in to Azure Portal as Global Administrator
 
2) Open Cloud shell (right hand corner)
 
ss1
 
3) Make sure you are using PowerShell Option
 
ss2
 
4) In my demo scale set configuration as following
 
New-AzureRmVmss `
  -ResourceGroupName "rebelResourceGroup" `
  -Location "canadacentral" `
  -VMScaleSetName "rebelScaleSet" `
  -VirtualNetworkName "rebelVnet" `
  -SubnetName "rebelSubnet" `
  -PublicIpAddressName "rebelPublicIPAddress" `
  -LoadBalancerName "rebelLoadBalancer" `
  -BackendPort "80" `
  -VmSize "Standard_DS3_v2" `
  -ImageName "Win2012Datacenter" `
  -InstanceCount "4" `
  -UpgradePolicy "Automatic"
 
In above,
 

Parameter

Description

New-AzureRmVmss

This is the command use to create Azure Virtual Machine Scale Set

-ResourceGroupName

This define the resource group name and it is a new one.

-Location

This defines the resource region. In my demo its Canada Central

-VMScaleSetName

This defines the name for the Scale Set

-VirtualNetworkName

This defines the virtual network name

-SubnetName

This defines the subnet name. if you do not define subnet prefix, it will use default 192.168.1.0/24

-PublicIpAddressName

This defines the name for public IP address. If not define allocation method using -AllocationMethod , it will use dynamic by default.

-LoadBalancerName

This defines the load balancer name

-BackendPort

This creates relevant rules in loadbalancer and load balance the traffic. in my demo I am using TCP port 80.

-VmSize

This defines the VM size. if this is not defined, by default it uses Standard_DS2_v2

-ImageName

This defines the VM image details. If no valuves used it will use default value which is Windows Server 2016 Datacenter

-InstanceCount

This defines the initial number of instance running on the scale set

-UpgradePolicy

This defines upgrade policy for VM instances in scale set

Once this is run it will ask to define login details for instances. After completes, it will create the scale set.

ss3

This also can do using Portal. In order to use GUI, 

1) Log in to Azure Portal as Global Administrator

2) Go to All Services | Virtual Machine Scale Set

ss4

3) In new page, click on Add

ss5

4) Then it will open up the form, once fill in relevant info click on create 

ss6

5) We also can review the existing scale set properties using Virtual machine scale sets page. On page click on scale set name to view the properties. If we click on Instances, we can see the number of instances running

ss7

6) Scaling shows the number of instances used. If need it can also adjust in here. 

ss8

7) Size defines the size of the VM, again if need values can change in same page. 

ss9

8) Also, if we go to Azure Portal | Load Balancers, we can review settings for load balancer used in scale set.

ss10

9) In my demo I used TCP port 80 to load balance. Those info can find under Load Balancing rules

ss11

10) Relevant public ip info for scale set can be find under inbound NAT rules

ss12

 

This marks the end of this blog post. In next post we will look in to further configuration of scale set. If you have any questions feel free to contact me on rebeladm@live.com also follow me on twitter @rebeladm to get updates about new blog posts.

How to re-enable Network Interface in Azure VM?

In Hyper-V or VMware virtualization environment, Enable/Disable NIC in a VM is not a big deal. Even if you do not have NIC or valid IP configure, administrators still can connect to VM as it does have “Console” access. Few weeks ago, I received an email from one of my regular blog readers. He accidently disabled NIC in azure vm and he lost RDP access to it. since there is no console access like other on-premises virtualization solution, of cause he was panicking. In this blog post I am going to share what you can do to re-enable your Azure VM NIC in such scenario. 

In my demo setup, I have an active azure VM running with 10.5.2.33 private IP address. 

ip1

I logged in to VM as administrator and disable the NIC.

Now I need to regain the RDP access to server. in order to do that, log in to Azure Portal as Global Administrator and click on Cloud Shell button in right hand top corner. 

ip2

When window load up makes sure you are using PowerShell option. 

ip3

Now we need to find out the NIC details of the VM that we having issues with. We can do this using,

Get-AzureRmNetworkInterface -ResourceGroupName "REBELADMIN-DEMO" 

In this command, -ResourceGroupName represent the resource group that VM belongs to. In my demo setup I only have one VM under that resource group.  but if you have more VMs it can be hard to find the relevant info. In that case I recommend to use portal itself to view this info.

In here, note down the network interface name, IP address and allocation method you using. 

ip4

Now, we need to assign a new IP address to the same nic from same subnet. It can be done using,

$Nic = Get-AzureRmNetworkInterface -ResourceGroupName "REBELADMIN-DEMO" -Name "rebeladmin-vm1123"

$Nic.IpConfigurations[0].PrivateIpAddress = "10.5.2.34"

$Nic.IpConfigurations[0].PrivateIpAllocationMethod = "Static"

$Nic.Tag = @{Name = "Name"; Value = "Value"}

Set-AzureRmNetworkInterface -NetworkInterface $Nic

In above commands, rebeladmin-vm1123 represent the network interface name. 10.5.2.34 is the new ip address for the network interface. PrivateIpAllocationMethod define the ip allocation method. Set-AzureRmNetworkInterface cmdlet sets the network interface configuration. 

ip5

Great!! Now I got my RDP access back with new IP address.

ip6

But it is not the original IP it had, now we can change it back with,

$Nic2 = Get-AzureRmNetworkInterface -ResourceGroupName "REBELADMIN-DEMO" -Name "rebeladmin-vm1123"

$Nic2.IpConfigurations[0].PrivateIpAddress = "10.5.2.33"

$Nic2.IpConfigurations[0].PrivateIpAllocationMethod = "Static"

$Nic2.Tag = @{Name = "Name"; Value = "Value"}

Set-AzureRmNetworkInterface -NetworkInterface $Nic2

ip7

Once it is applied, I can access server via RDP and now it has same private IP address it had.

ip8

If you using dynamic IP allocation method, you need to make it static, then change the ip and go back to dynamic mode. 

This marks the end of this blog post. If you have any questions feel free to contact me on rebeladm@live.com also follow me on twitter @rebeladm to get updates about new blog posts.

Step-by-Step Guide to setup Just-in-Time VM Access in Azure

In most common scenarios hackers targets open ports in servers to gain access. It can be web server port, RDP ports, SQL ports etc. If genuine users also use same ports to access the system it’s hard to keep these ports closed. There are other methods such as firewalls that we can use to secure the access but it will still keep the ports open. when it comes to public clouds, its increase your infrastructure’s public facing part. Its clients, administrators may access services over the internet mostly. In that case it will give more time and room for attackers to target open ports. 

Azure Just-in-Time VM Access is a great option to control this. As an example, if engineers need to do work in their VM’s mostly they RDP in to the system. Let’s assume they work 1 hour per day on servers. so, keeping port open for 24 hours not giving any benefits rather than risk. Using Just-in-Time VM Access we can limit the time it keeps RDP ports open. 

When Just-in-Time VM Access enabled, we can define what VM and what ports will be controlled. In most scenarios you do not need to control access to ports used by your applications or services. It will be more in to ports related to management tasks. This all done by using azure network security group rules. You can find more about NSG using https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-nsg

When this feature used with VM, upon access request to a protected port, it will first check if the user have access permission to it using Azure Role based access control (RBAC). If it all good, then NSG automatically configure to allow access with the time you specified. Once it reached the allowed time limit, NSG will automatically revert configuration in to original state. 

This feature is still on preview but it is not too early to check its capabilities. Also, this feature is only can use with VMs created using Azure Resource Manager (ARM). 

Configuration

1. Log in to Azure Portal using Global Administrator account. 

2. Go to Security Center > Just-In-Time VM Access 

jvm1

3. Then it will load the default page.

jvm2

4. Click on Recommended Tab. It will list down the VMs you have. 

jvm3

5. In order to enable JIT access, put a tick on the VM you like to protect and then click on Enable JIT on button. if need you can do it for multiple VMs in same time. 

jvm4

6. Then it lists down the default ports protected with JIT access. 

jvm5

7. We still can adjust settings for these services. As an example, I need to limit port 3389 (RDP) port Max request time to 1 hour. By default, it is 3 hours. In order to do that click on rule for 3389 and change Max request time value to 1 hour. To apply changes, click on OK at the end.

jvm6

8. In next window we can see the new value, click on Save to save the config. 

jvm7

9. If need we also can add our own ports to protection. Let’s assume we need to protect port 8080 access. To do that click on Add button in access configuration page. 

jvm8

10. Then type port details in the window. Under Protocol we can select TCP, UDP or Any based-on requirement. Under Allowed source IPs access can controlled based on request or specific IP range. Max request time option is to limit the hours. Minimum time we can select is 1 hour. Once changes are done click on OK to apply changes

jvm9

11. Then click on Save to save the config. 

12. After that, once we go to feature home page we can see the protected VM under Configured tab.

jvm10

13. If need to edit the current configuration it can do using Edit option as below. 

jvm11

14. Now configuration is done. Let’s test it out. According to my configuration I have RDP port protected. To request access, select the VM with tick box and then click on request access option. 

jvm12

15. In next window, I am only going to request access to RDP port. To do that select the correct rule and click on On tab under toggle. Then click on Open Ports button. 

jvm13

16. Then in the feature home page we can see it got 1 approved requests.

jvm14

17. After configuration yes, I can access the server via RDP for 1 hour.

jvm15

18. After one hour, I can’t initiate another new RDP connection. Using Activity log we can view logs related to past activities. 

jvm16

jvm17

This marks the end of this blog post. Hope now you have better understanding what is JIT VM access and how to use it. If you have any questions feel free to contact me on rebeladm@live.com also follow me on twitter @rebeladm to get updates about new blog posts.

Introducing change tracking and inventory features for Azure VM

In any infrastructure, users are using different applications, services, file shares in order to get their work done. each of these components may have periodic changes. In order to maintain integrity, provide faster IT support and identify risks, it is important to track all the changes against these components. Maintaining inventory (software level) will help engineers to verify if systems are running as expected with relevant software and services. Change tracking and inventory process can be done using software or workflows. 

Operation Management Suite (OMS) provides solution called “Change Tracking” to capture changes in cloud only, hybrid or on-premises only environments. It can track changes on Files, Registry Entries, Software, Windows services and Linux Daemons. 

ch1

Microsoft recently release “Change tracking and Inventory” solution which can implement in Azure VM level. However, this is not replacement for OMS solution. OMS can track changes on any environment whiles this new solution is just for cloud only servers. 

There are few things I like about this solution,

1. Easy to implement – with few clicks this feature can be enable in VM level.

2. No Agents – It doesn’t need agents to track changes or maintain inventory. 

3. No need to log in to VM – It is not required any user interaction or system credentials, in order to use these features. Engineers can view visualized data without login to VM. 

4. No scheduled scans – It tracks changes automatically. you do not need to manually create scan jobs or update schedules. (however, in background jobs are controlled by azure automation) 

Please note this is still in preview mode, there for not recommended to use in production environment. But it is not too early to try its capabilities.  

Let’s go ahead and see how we can enable and use this feature. 

1. Log in to Azure portal (https://portal.azure.com) as Global Administrator.

2. Go to Virtual Machines and click on the VM you like to get this feature enabled. 

3. In VM panel, under OPERATIONS section click on Inventory (preview) 

ch2

4. Then it will load up detail window, click on purple color bar like in below image to enable the feature. 

ch3

5. Then it will load up new window with information such as log analytic workspace id and automation account id. Click on Enable to proceed. 

ch4

6. Once feature is enabled we can see following window. It will take while to populate data.

ch5

7. It also enables the Change tracking (preview) feature. 

ch6

8. After sometime you will be able to see data under Inventory (preview) and Change tracking (preview) windows. Let’s start with Inventory (preview). When I load the window, first it lists down the software installed in the system. 

ch7

9. This includes information about windows updates and all other third-party applications. If it’s a software, it displays the version number and publisher’s info. As an example, I install acrobat reader and I can see its info as following. 

ch8

10. Under the Files tab we can see the files details. By default, it doesn’t scan for any files. In system, there are thousands of files, it is no point to add all those to inventory. Instead of that users can define what folders and files to monitor and add to inventory. If its folder, it will list all these files under that particular folder automatically. In order to do that, click on Edit Settings Option.

ch9

11. In next window, click on Windows Files tab. 

ch10

12. Then click on Add in next window. 

ch11

13. In next window, type a unique name for the file or folder under Item Name. Then type folder or file path under Enter Path. Once everything done, click on Save

ch12

14. Once its added it will show under Windows Files tab. If you need to disable inventory and change tracking for a file or folder all you need to do is click on it and click on false button under Enabled.

ch14

15. If it’s a Linux system, files and folder paths can add using Linux Files tab. 

ch15

16. When we add files here, it is automatically enable change tracking for those files and folders. So, you do not need to add it again under change tracking feature. 

17. Under Registry Files tab we can enable registry files tracking and inventory as well. It does have pre-defined registry path but at the moment I can see a way to add custom path. To enable feature, click on registry entry, then click on True under enabled. In the end click on Save

ch16

18. This also enable tracking for windows registry files under change tracking feature. 

19. Under Windows services tab, it lists all services in the system. It also shows its current status and startup status.

ch17

20. This is just for one VM, if you need to view multiple VM inventory data, you need to click on Manage multiple computers.

ch18

21. In new window, it lists the machines which has this feature enabled. 

ch19

22. If you need to add new VMs to the list, it can be done using Add Azure VM option. Then it will allow you to enable inventory feature. 

ch20

23. There is option to add non-azure virtual machines too. but that will lead you to OMS.

24. All other windows are familiar, only change here you can see if the same event is repeated in different computers. 

ch21

25. All the events in here also can view using log analytics. In order to access that, click on Log Analytics option in main window. 

ch22

26. Then it will load all the events and we can find relevant info using queries or just browsing through filters. 

ch23

27. Now we done with inventory feature and let’s move in to Change tracking (preview) feature. In order to access the feature just click on Change tracking (preview) option under operations. 

ch24

28. As soon as login it shows the changes for last 24 hours. It is shows as graph as well as a list. 

ch25

29. Using Time Range dropdown, we can define the time range for data. 

ch26

30. Using Change Types dropdown, we can select which type of data to view. 

ch27

31. The graph itself really useful to narrow down a change quickly. All you need do is move mouse over the timeline and then select the area you like to dig in to by dragging the cursor. Then it simple list down the results for that particular time. 

ch28

32. Using Manage multiple computers option we can view changes for multiple computers in same window. It works same way it works in inventory feature.

ch29

33. Edit Settings option also same as in inventory feature. So, I am not going to cover it here. 

34. In main window, there is option to manage connection with azure activity log. There you can enable integration with azure activity log. You can find more info about activity log in https://docs.microsoft.com/en-us/azure/monitoring-and-diagnostics/monitoring-overview-activity-logs

ch30

This marks the end of this blog post. If you have any questions feel free to contact me on rebeladm@live.com also follow me on twitter @rebeladm  to get updates about new blog posts.  

Update Management for Azure VM

Keeping your operating systems up-to-date is critical as it will be the first step towards protecting your systems from emerging threats. it will also help to improve efficiency and user experience. Simplest way to update your windows operating systems to use “Windows Update” feature comes with every operating system. But this is not enough for corporates as it is important to manage windows updates in control manner. Microsoft has tools such as WSUS, SCCM to manage windows update in infrastructure. when it comes to hybrid or cloud only environment it is important update your virtual machines running on cloud as well. Microsoft Operation Management Suite (OMS)’s “Update Management” is a great way to manage updates in any environment (on-premises, cloud only or hybrid). It detects and report missing updates in your environment. It also allows to deploy those using Azure automation. 

update1

However, if you running an azure environment, now Microsoft have another solution which will help to manage updates for Azure VMs. This is NOT a replacement for OMS update management even though it works similar. it helps to manage updates in individual VM level or as group. This feature “Update Management” still in preview mode but it is not too early to try its capabilities. 

There are few things I like about this feature.

1. No Agents or additional configuration – This feature can enable under a VM with few clicks and it doesn’t require any additional configuration inside the VM. It doesn’t need any agent installation or any other configuration such as firewall changes. It’s simple and efficient. 

2. No need to log in to VM – This is ideal for MSPs as well. In order to manage updates, you do not need to log in to VM at all. No need to define passwords to install updates either. 

3. Reporting – It list down missing updates and categories those based on type. It lists info about failed deployments. So, everything been logged and visualized in easy way to understand. 

Let’s see how we can get this setup.

1. In order to enable this feature, you need to log in to Azure as global administrator. 

2. The click on Virtual Machines to list down VMs.

update2

3. Then click on the VM which you choose. 

4. From left hand side panel, click on Update Management (Preview)

update3

5. In next window click on purple bar (as in following image) to enable the feature. 

update4

6. Then it will load the page to enable to feature. As we can see it is also creating log analytic workspace as well as automation account. Click on Enable to proceed. 

update5

7. Once it is enabled, it will take 15-20 minutes to gather information about updates. Once it is finish we can see new data under Update Management (Preview) panel. 

update6

8. In Missing Update section, it shows update name, classification, published date and link to see more details about updates. 

update7

9. If we click on one of missing updates it will bring to us to the log search window and in there we can see more details about update. 

update8

10. In Update Management (Preview) panel, lets click Manage Multiple Computers Option. 

update9

11. In that window, we can see all the computers which have this feature enabled and their compliance status. 

update10

12. By clicking on each computer in list, we can see more detail about it using log search window.

update11

13. We also can add Azure VM to update management. To do that click on Add Azure VM option in Manage Multiple Computers panel. 

update12

14. It will list the VMs in account and click on the relevant VM you like to add. Then we can enable the feature under it. 

update13

15. Now we have list of missing updates. Next step is to schedule update. In order to do that go back to Update Management (Preview) panel and click on Schedule update deployments option. 

update14

16. In new window, first thing is to define name for the job. Under Update classification we can select which updates to consider for the schedule. 

update15

17. If need to exclude any updates, we can do that using updates to exclude option. In there we need to define relevant KB numbers. 

update16

18. Under the schedule settings we can define the time to apply updates. It can be either one time or recurring job. 

update17

19. Using maintenance window option we can set how long it should be in maintenance mode. 

update18

20. Once it’s done click on Create to create the schedule. 

update19

21. If you use the same Schedule update deployments option under Manage Multiple Computers window, we can create schedule for multiple computers. 

update20

22. Once schedule is created we can see it under Scheduled update deployments tab. 

update21

23. This completes the configuration part and once schedule run, we can verify it using Update Management (Preview) panel 

This marks the end of the blog post and hope it was useful. If you have any questions feel free to contact me on rebeladm@live.com also follow me on twitter @rebeladm to get updates about new blog posts.

Step-By-Step guide to create Azure VM using Azure CLI 2.0

In my previous blog post I have explain what is Azure CLI and how we can integrate it with windows system. If you didn’t read it yet please look in to it before we continue on this post. You can find it on http://www.rebeladmin.com/2017/08/step-step-guide-start-azure-cli-2-0/

In this blog post I am going to demonstrate how we can create Azure VM using Azure CLI. 

1) Log in to Azure CLI using az login (This is explained on my first blog. If you using cloud shell this is not necessary. All you need to do is launch it on the portal)

clivm1

2) Next step on process is to create resource group. before we create we need to know the available locations. So, we can create resource group under relevant geographical location. To list down the locations, run az account list-locations

clivm2

In my demo I am going to create resource group called “rebeladminrg01” under west us. The command for that task will be az group create --name rebeladminrg01 --location westus. In above –name specify the resource group name and –location specifies the geographical location. 

clivm3

3) Next step is to create a virtual network under my new resource group. for that I am going to use 

az network vnet create --name rebeladminVNet --resource-group rebeladminrg01 --location westus --address-prefix 10.10.0.0/16

In above command –name specify the virtual network name. in sample, it is rebeladminVNet. --resource-group defines the resource group it belongs to. In above –location specify the geographical location it belongs to. --address-prefix specify the address space associated with the virtual network.

clivm4

4) Now we have virtual network, next step is to create subnet 10.10.20.0/24 under the virtual network rebeladminVNet. In order to do that I am going to use,

az network vnet subnet create --address-prefix 10.10.20.0/24 --name rebeladminsub1 --resource-group rebeladminrg01 --vnet-name rebeladminVNet

in above, --address-prefix specify the address space for the subnet. –name specify the name of the subnet. --resource-group specify the resource group new subnet belongs to. --vnet-name specify the virtual network it is belongs to. 

clivm5

5) let’s also associate a new public IP address with virtual network, so we can use it to connect from external to new vm that we about to create. 

az network public-ip create --name rebeladminpubip1 --resource-group rebeladminrg01 --location westus --allocation-method dynamic

In above –name specify the name of the public IP instance. --resource-group defines the resource group name it belongs to. –location specifies the georgical location resource belongs to. --allocation-method specifies the public IP allocation method. It can be static IP or dynamic Ip assignment. In this demo, I am going to use dynamic method. 

clivm6

6) Next step on the process to create NIC so we can attach it to VM. 

az network nic create --resource-group rebeladminrg01 --name rebeladminNic1 --vnet-name rebeladminVNet --subnet rebeladminsub1 --public-ip-address rebeladminpubip1

in above sample, --resource-group defines the resource group name it belongs to. --vnet-name specify the virtual network it is belongs to. –subnet specify the subnet it associated with. --public-ip-address specify the public ip address this NIC will associate with. 

clivm7

Now we have components needed for the vm (except storage, I will cover storage on different post. In here I will be using Azure managed disks). We can review the details about the resource we created using az resource list -g rebeladminrg01 this will list down the resource under resources group rebeladminrg01

clivm8

Some data such as subnet info will not display by using above command. Those can view using list command combine with resources group and parent resources. as an example, to view subnet info under the virtual network we can use,

az network vnet subnet list --vnet-name rebeladminVNet -g rebeladminrg01

in above --vnet-name specify the virtual network name and -g specify the resource group name. 

clivm9

7) Now it’s all ready, lets create first windows VM using the resource we created on previous steps. 

az vm create --resource-group rebeladminrg01 --location westus --nics rebeladminNic1 --name REBLEVM101 --image win2016datacenter --admin-username rebeladmin --admin-password Pa$$w0rd123456

in above, --resource-group specify the resources group VM belong to. –nics specify the network interface associated with the VM. –name is the VM name. –image specify the virtual machine image going to use with VM. You can get list of entire image list using az vm image list --output table –all

in sample --admin-username defines the admin user name for the new vm and --admin-password defines the VM password. 

clivm10

this creates the VM successfully. 

clivm11

In this demo, I explain how to create VM using azure cli. Hope this was useful and in next post on Azure CLI I will cover about storage. If you have any questions, feel free to contact me on rebeladm@live.com 

Setting up Azure Virtual Machines with Terraform

In my previous article about terraform, I explain what is terraform and what it can do. Also, I explain how to set it up and how we can use it with Azure to simplify infrastructure configuration. If you didn’t read it before you can view it using this link  

In this post, we are going to look further in to Azure infrastructure setup using terraform.

Before that lets look in to sample configuration of an Azure resource and see how syntax been used.

resource "azurerm_resource_group" "test" {

  name     = "acctestrg"

  location = "West US"

}

 resource "azurerm_virtual_network" "test" {

  name                = "acctvn"

  address_space       = ["10.0.0.0/16"]

  location            = "West US"

  resource_group_name = "${azurerm_resource_group.test.name}"

}

Above code is to create an Azure resource group and Azure virtual network. In the code azurerm_resource_group and azurerm_virtual_network defines the azure resource type. The text test defines the name for that resource instance. This is not the azure resource group or azure virtual network name. This is the instance name. so, if you have another resource group it can be test2. Actual resource names are defined using name attribute. So, in above code the actual resource name for resource group is acctestrg and for virtual network its acctvn.

In above example, new virtual network is need placed under the acctestrg resource group. in the code it is defined using,

resource_group_name = "${azurerm_resource_group.test.name}"

in there, by azurerm_resource_group.test it defines the related resource group instance. In our example, it is test. Then using .name it calls for the attribute value of name under that particular resource group.

In the plan stage terraform creates the execution plan. It does not process the code top to bottom. It evaluates the code and then build the plan logically. There for it no longer consider the resource order. Let’s try it with an example, 

resource "azurerm_virtual_network" "test" {

  name                = "acctvn"

  address_space       = ["10.0.0.0/16"]

  location            = "West US"

  resource_group_name = "${azurerm_resource_group.test.name}"

}

 resource "azurerm_resource_group" "test2" {

  name     = "acctestrg2"

  location = "West US"

}

 resource "azurerm_virtual_network" "test2" {

  name                = "acctvn2"

  address_space       = ["11.0.0.0/16"]

  location            = "West US"

  resource_group_name = "${azurerm_resource_group.test2.name}"

}

 resource "azurerm_resource_group" "test" {

  name     = "acctestrg"

  location = "West US"

}

In above example, I am creating two resources group and two virtual networks. If you look in to highlighted sections, I placed the code related to virtual network before creating resources group. But when I run terraform plan it creates the execution plan in correct order.

tf1 

And once it is executed, it creates the expected resources.

tf2

As next step on demo, let’s see how we can create virtual machines in Azure using terraform.

resource "azurerm_virtual_machine" "testvm" {

  name                  = "acctvm"

  location              = "West US"

  resource_group_name   = "${azurerm_resource_group.test.name}"

  network_interface_ids = ["${azurerm_network_interface.test.id}"]

  vm_size               = "Standard_A0"

above code is an example to create a VM in azure. In code sample, azurerm_virtual_machine defines the resource type. testvm is the resource instance name. acctvm is the name of the virtual machine. According to code the resource will deploy under West US region. resource_group_name defines the resource group it belongs to. network_interface_ids defines the network interface id for the VM. vm_size defines the Azure VM template. The template list for the region can list down using following Azure CLI command.

az vm list-sizes --location west-us

This will list down the all available VM sizes in West US region.

tf3

Azure VM also need other components such as virtual network, storages, operating system so on. Let’s see how we can add these to the configuration.

In earlier on the post, I share samples for creating a resources group and virtual network. The next step of it will be to add a subnet under the virtual network.

resource "azurerm_subnet" "sub1" {

  name                 = "acctsub1"

  resource_group_name  = "${azurerm_resource_group.test.name}"

  virtual_network_name = "${azurerm_virtual_network.test.name}"

  address_prefix       = "10.0.2.0/24"

}

In above I am creating a subnet 10.0.2.0/24 under virtual network and resources group I already have. In code, azurerm_subnet defines the resource type. sub1 is the instance name and acctsub1 is the subnet name. resource_group_name defines on which resources group it belongs to. virtual_network_name defines which azure virtual network it associated with. address_prefix specifies the subnet value.

Now we have subnet also associated with network. We also need public IP address in order to connect to VM from internet. 

resource "azurerm_public_ip" "pub1" {

  name                         = "pub1"

  location                     = "West US"

  resource_group_name          = "${azurerm_resource_group.test.name}"

  public_ip_address_allocation = "dynamic"

}

According to above, I am creating public IP instance called pub1 under same resource group. it’s IP allocation is set to Dynamic. If need it can be static as well.

Next step is to create network interface for the VM.

resource "azurerm_network_interface" "ni1" {

  name                = "acctni1"

  location            = "West US"

  resource_group_name = "${azurerm_resource_group.test.name}"

ip_configuration {

    name                          = "lan1"

    subnet_id                     = "${azurerm_subnet.test.id}"

   private_ip_address_allocation = "dynamic"

   public_ip_address_id  = "${azurerm_public_ip.pub1.id}"

  }

In above azurerm_network_interface is the resource type for the network interface. the interface name we are creating is acctni1. the second part of code which starts with ip_configuration defines the IP configuration for the network interface. subnet_id defines the subnet it belongs to. private_ip_address_allocation defines the ip allocation method. It can be Dynamic or Static. public_ip_address_id associates with the public ip created in the previous step. If this is not done you will not be able to connect to VM remotely once it is deployed.    

Next thing we need for the VM is storage. Let’s start with creating a Storage Account 

resource "azurerm_storage_account" "asa1" {

  name                = "accsa"

  resource_group_name = "${azurerm_resource_group.test.name}"

  location            = "westus"

  account_type        = "Standard_LRS"

 }

azurerm_storage_account is the resource type and accsa is the name for the account. account_type defines the storage account type. it can be Standard_LRS, Standard_GRS, Standard_RAGRS, Standard_ZRS, or Premium_LRS. More info about these account types can find from https://docs.microsoft.com/en-us/azure/storage/storage-introduction .

as next step, we can create a new storage container under the storage account.

resource "azurerm_storage_container" "con1" {

  name                  = "vhds"

  resource_group_name   = "${azurerm_resource_group.test.name}"

  storage_account_name  = "${azurerm_storage_account.test.name}"

  container_access_type = "private"

}

In above azurerm_storage_container is the resource type and it name is vhds. resource_group_name defines the resource group it belongs to and storage_account_name defines storage account it belongs to. container_access_type can be private, blob or container. More info about these container types can find from https://docs.microsoft.com/en-us/azure/storage/storage-introduction

Following image shows what it looks like when using GUI option. 

tf4

By now we have most of the resources ready for the VM. Next step is to define image for the VM.

  storage_image_reference {

    publisher = " MicrosoftWindowsServer"

    offer     = " WindowsServer"

    sku       = " 2016-Datacenter"

    version   = "latest"

  }

In above I am using windows server 2016 datacenter as image for the VM. Publisher, offer, sku and version info need to provide in order to select correct image. For windows servers, you can find these info in https://docs.microsoft.com/en-us/azure/virtual-machines/windows/cli-ps-findimage. For Linux, this info available at https://docs.microsoft.com/en-us/azure/virtual-machines/linux/cli-ps-findimage

Next step is to add a hard disk,

storage_os_disk {

    name          = "myosdisk1"

    vhd_uri       = "${azurerm_storage_account.test.primary_blob_endpoint}${azurerm_storage_container.test.name}/myosdisk1.vhd"

    caching       = "ReadWrite"

    create_option = "FromImage"

  }

  storage_data_disk {

    name          = "datadisk0"

    vhd_uri       = "${azurerm_storage_account.test.primary_blob_endpoint}${azurerm_storage_container.test.name}/datadisk0.vhd"

    disk_size_gb  = "60"

    create_option = "Empty"

    lun           = 0

  }

Above create two disks. one is for OS and one is for data. vhd_uri defines the path for the VHD which is saved under the storage account created.

Last but not least we need to define the OS configuration data such as hostname and administrator account details.

  os_profile {

    computer_name  = "rebelpro1"

    admin_username = "rebeladmin"

    admin_password = "Password1234!"

  }

In above, computer_name specify the hostname of the VM. admin_username specify the local administrator name and admin_password specify the local administrator password.

Now we have all the components ready to deploy a new VM. Some of the components we just need to create one time. as example virtual networks, subnets, storage accounts not need to create for each VM unless there is valid requirement. Let’s put all these together in to a one script so it will make more sense. 

# Configure the Microsoft Azure Provider

provider "azurerm" {

  subscription_id = "d7xxxxxxxxxxxxxxxxxxxxxx"

  client_id       = "d9xxxxxxxxxxxxxxxxxxxxxx"

  client_secret   = "f1xxxxxxxxxxxxxxxxxxxxxx "

  tenant_id       = "05xxxxxxxxxxxxxxxxxxxxxx "

}

resource "azurerm_resource_group" "rg1" {

  name     = "acctestrg"

  location = "West US"

}

resource "azurerm_virtual_network" "vn1" {

  name                = "vn1"

  address_space       = ["10.0.0.0/16"]

  location            = "West US"

  resource_group_name = "${azurerm_resource_group.rg1.name}"

}

resource "azurerm_public_ip" "pub1" {

  name                         = "pub1"

  location                     = "West US"

  resource_group_name          = "${azurerm_resource_group.rg1.name}"

  public_ip_address_allocation = "dynamic"

}

resource "azurerm_subnet" "sub1" {

  name                 = "sub1"

  resource_group_name  = "${azurerm_resource_group.rg1.name}"

  virtual_network_name = "${azurerm_virtual_network.vn1.name}"

  address_prefix       = "10.0.2.0/24"

}

resource "azurerm_network_interface" "ni1" {

  name                = "ni1"

  location            = "West US"

  resource_group_name = "${azurerm_resource_group.rg1.name}"

 

  ip_configuration {

    name                          = "config1"

    subnet_id                     = "${azurerm_subnet.sub1.id}"

    private_ip_address_allocation = "dynamic"

    public_ip_address_id  = "${azurerm_public_ip.pub1.id}"

  }

}

 resource "azurerm_storage_account" "storevm123" {

  name                = "storevm123"

  resource_group_name = "${azurerm_resource_group.rg1.name}"

  location            = "westus"

  account_type        = "Standard_LRS"

 

  tags {

    environment = "demo"

  }

}

 resource "azurerm_storage_container" "cont1" {

  name                  = "vhds"

  resource_group_name   = "${azurerm_resource_group.rg1.name}"

  storage_account_name  = "${azurerm_storage_account.storevm123.name}"

  container_access_type = "private"

}

 resource "azurerm_virtual_machine" "vm1" {

  name                  = "vm1"

  location              = "West US"

  resource_group_name   = "${azurerm_resource_group.rg1.name}"

  network_interface_ids = ["${azurerm_network_interface.ni1.id}"]

  vm_size               = "Standard_DS2_v2"

 

   storage_image_reference {

    publisher = "MicrosoftWindowsServer"

    offer     = "WindowsServer"

    sku       = "2016-Datacenter"

    version   = "latest"

  }

   storage_os_disk {

    name          = "osdisk1"

    vhd_uri       = "${azurerm_storage_account.storevm123.primary_blob_endpoint}${azurerm_storage_container.cont1.name}/osdisk1.vhd"

    caching       = "ReadWrite"

    create_option = "FromImage"

  }

   storage_data_disk {

    name          = "datadisk1"

    vhd_uri       = "${azurerm_storage_account.storevm123.primary_blob_endpoint}${azurerm_storage_container.cont1.name}/datadisk1.vhd"

    disk_size_gb  = "60"

    create_option = "Empty"

    lun           = 0

  }

     os_profile {

    computer_name  = "rebelpro1"

    admin_username = "rebeladmin"

    admin_password = "Password1234!"

  }

   tags {

    environment = "demo"

  }

}

Let’s verify the resources using Azure portal.

As we can see it is created all the expected resource under the resource group acctestrg.

tf5

Also, we can see it is created the VM as expected.

tf6

In this post, we went through the process of creating Azure VM and related components using terraform. Hope this was useful and if you have any questions feel free to contact me on rebeladm@live.com

Step-by-Step Guide to assign Reserved IP address to Azure VM

In azure all the IP address assignments are dynamic by default. Which means IP addresses can change in restart. There are 2 methods you can use to assign IP address to a VM in azure. its dynamic and static

Why we need static IP addresses ?

1) Application requirements – sometime applications need to connect with fixed IP address. For example, if it’s a database VM it’s important to have static IP address so application settings always can refer to that. 

2) Security – when VM uses static IP addresses we can create firewall rules easily. So there is more control over traffic flow as well. 

In azure, static IP address (public) is count as a service so there will be addition charge for it. 

In azure there is 2 methods to deploy and manage a VM. 

1) By Using Classic Mode

2) By Using Resources Manager 

Assigning a static IP address (public) is different for these 2 methods. In this blog post I am going to demonstrate how to do it using both modes. 

Assign Static IP Address in classic deployment model

Before we start need to make sure following prerequisites are in place. 

Global Administrator account for the Azure Subscription

Azure PowerShell Module installed in local computer – you can download it from http://aka.ms/webpi-azps

In my demo I got a classic virtual machine running and it’s got dynamic public IP address assigned. In demo I am going to show how we can make it as reserved IP address. 

1) Log in to PC where Azure PowerShell Module installed and open the powershell as administrator

2) Then type Add-AzureAccount and press enter

3) Then it will prompt for the azure credential and login as global administrator

rip2

4) Then type New-AzureReservedIP –ReservedIPName DCM01ReservedIP –Location "East US" -ServiceName DCM01  – in the command DCM01ReservedIP is the name for the reserved IP address and Location define the location of the IP address ( can be US, Europe etc.). 

rip3

5) Now it’s done and when I go to DCM01 VM now its shows the IP address as reserved. 

rip4

6) Also in power shell type Get-AzureReservedIP and it will show the reserved IP details 

rip5
 

Using Resource Manager deployment mode

In the resource manager I have a VM running and the public address by default. I need to change it to static. 

rip6

1) To change click on the VM from the virtual machine container 

2) Then click on the public IP address and DNS name

rip7

3) Then it will load the configuration and to change click on the configuration option

rip8

4) It will then list down the public IP configuration, as can see by default its dynamic to set it to static need to click on static option and click on save. This will make the IP address static.

rip9

rip10

Hope this post was helpful and if you have any question feel free to contact me on rebeladm@live.com