Azure: Application Gateway HTTP to HTTPS redirect

One key feature of the Application Gateway service is its support for Secure Sockets Layer (SSL) termination. This feature means that the overhead of encrypting and decrypting traffic can be offloaded to the gateway, rather than have this impact performance on the backend web server.

This does however mean that communication between the application gateway and the backend web server is unencrypted which in some cases, perhaps due to security or compliance requirements, may not be acceptable. For those situations, the application gateway also fully supports end to end SSL encryption.

For the purpose of this article, the assumption has been made that SSL termination is enabled on the gateway. Standard web traffic should now be redirected to the HTTPS listener so that web requests don’t just fail when they are unable to traverse the application gateway over HTTP.

Enabling HTTP to HTTP redirection

When an application gateway is configured with SSL termination, a routing rule is used to redirect HTTP traffic to the HTTPS listener. The remainder of this article steps through configuring this routing rule.

Assumptions

The following assumptions have been made:

  • HTTP and HTTPS listeners already exist
  • Azure PowerShell module version 3.6 or later is installed.

NOTE: To check what version of PowerShell is installed and for help on upgrading it if required, see Install Azure PowerShell module.

Configuring the routing rule

1. The first thing we need to do is get the application gateway object and store it as a variable

2. Get the existing HTTPS listener

3. Get the existing HTTP listener

4. Now create a redirection configuration using a permanent redirect and targeting the existing listener

5. Get the newly created redirect configuration

6. Add a new rule to handle the redirect from the HTTP listener

7. Finally, update the application gateway

To make it a little simpler to copy all steps, they have been combined into one script below. A copy of the file can also be downloaded from my GitHub repository app-gateway-http-https-redirect.ps1

More information about the application gateway and all of its features can be found by following the link to Microsoft document repository – https://docs.microsoft.com/en-us/azure/application-gateway/

Azure: Using Azure Event Grid to trigger Automation Runbooks

A relatively new service that so far has been somewhat overlooked by many of the customers I have spoken with, is the Azure Event Grid. Event Grid closely resembles Amazons Simple Notification Service, albeit under the hood they function a little differently.

With the cloud becoming increasingly event-driven, Event Grid has been labelled as the event messaging service for the modern application.

Essentially, the service can be used to intelligently route events between event publishers and event subscribers. Using Event Grid, events generated by Azure resources can be subscribed to, in turn used to trigger a reaction using one of the serverless technologies like Azure Automation or Logic Apps.

The Microsoft graphic above gives a basic representation of the service, including some of the event sources and event handlers available at the time of writing. As with everything in Azure, Microsoft are continuously working behinds the scenes to develop the service further. As such, other event sources and event handlers are planned for later this year include Azure Active Directory, API Management, Azure Data Lake Store, Azure Cosmos DB, Azure Data Factory, and Storage Queues.

For the latest event sources and event handlers refer to the following Microsoft blog
https://docs.microsoft.com/en-gb/azure/event-grid/overview#event-sources

Use cases

Event Grid can be used to develop Serverless Application Architectures, Ops Automation and Application Integration with Ops Automation being the focus of this article.

To give a few examples of how the service might be used for Ops Automation:

  • Notifying when Azure resources have been created or changed i.e. Virtual Machines or SQL Databases
  • Converting Virtual Machines deployed using unmanaged disks into managed disk machines
  • Assigning resource tags to resources when deployed to specific Resource Groups.

Using this style of serverless architecture, opens the door to designing solutions with almost limitless functionality.

Using Event Grid

The remainder of this article steps through implementing a very basic Event Grid deployment. In the demo, every time a Virtual Machine is deployed to a specific Resource Group, Event Grid, using a Webhook, triggers an automation Runbook which sends out email notification.

Assumptions

The following assumptions have been made:

  • Azure Automation Account has been created
  • Runbook with the required workflow has already been created and published.


The first thing to do is add a Webhook to the Runbook that will be triggered on an event being raised. To do this, browse to the Runbook and from its blade select Webhooks.


Next click + Add Webhook.


Give the Webhook a name and copy its endpoint URL to one side to be used later. Then Click OK to move onto configuring parameters and run settings for the selected Runbook. In my case, I can leave all parameters as default for the purpose of the demo.

Finally go ahead and create the Webhook by clicking the Create button.


The next step is to plumb all the components together, which is done by configuring an Event Grid subscription.

Selecting the Automation Account in which the Runbook we need to trigger is associated, click on Event Grid from the blade of the Automation Accounts overview page.


Click on the + Event Subscription button at the top of the Event Grid window.


Start by giving the subscription a name and then fill in the remaining options. For the purpose of this article, the following configuration was used:

  • Topic Type – Azure Subscriptions
  • Subscribe to all event types – unchecked
  • Event Topics – Resource Write Success selected only
  • Subscriber Endpoint – Webhook URL made note of earlier
  • Prefix Filter – Location of where the new VMs will be created.
    /subscriptions/<subscription-id>/resourcegroups/<resource-group-name>/providers/Microsoft.Compute/virtualMachines

Once all required options have been completed, finally click Create to deploy the subscription.


Now it’s time to test!

Go ahead and create a new Virtual Machine in the Resource Group that was specified in the Event Grid subscription. In my case Production-VMs.


If everything has gone to plan, on completion, a Resource Write Success event was raised which the Event Grid subscription successfully intercepted. This in turn used the Webhook to trigger the Automation Runbook to send out email notification.


In my case the notification was very basic and prepopulated with static content but this could be updated to include Virtual Machine names and other more useful information.

As you can appreciate, this is a very basic example of what the service is capable of when in reality, the sky is the limit!

Pricing

Event Grid price model is based on operation performed, so you only pay for what you use as with many other of the Azure services. Operations can include ingress events, advanced match, delivery attempt and management calls.

  • The first 100,000 operations per month are free
  • Price per million operations £0.448 *

* Based on West Europe pricing on the 6th April 2018

The only thing to keep in mind is that although more regions will no doubt come online soon. At the time of writing, Event Grid is only available in the following regions:

West US, East US, West US 2, East US 2, West Central US, Central US, West Europe, North Europe, Southeast Asia, and East Asia.

SLA

Guaranteed 99.99% or greater uptime.

For more information on Event Grid checkout the following Microsoft Blog https://docs.microsoft.com/en-gb/azure/event-grid/

Azure: Using Service Health to alert about planned maintenance

Microsoft periodically perform updates to improve the reliability, performance, and security of their global cloud platform. Most of the updates that Microsoft apply have no impact on the hosted virtual machines and go unnoticed. However, there are some instances where the running virtual machines are affected, the most recent example of this being the Spectre and Meltdown CPU vulnerability.

When an update like this is applied, depending if the maintenance requires a rebooted or not, it can affect running virtual machines in one of two ways:

  • In-place migration – During an in-place migration the affected Azure virtual machine is paused (typically for 30 seconds or less) to preserve memory in RAM while the host environment is updated. Once the upgrade is complete the virtual machine is resumed and the system clocks synchronised
  • Maintenance requiring a reboot – During reboot maintenance, the virtual machine is moved to a node that has already been patched and then powered back on.

Under normal circumstances, when a virtual machine needs rebooting, you are notified in advance and given the option to start the maintenance at a preferred time during the initial self-service window. If the self-service window is missed, the scheduled maintenance window begins and it is no longer possible to manage the process.

NOTE: Datacentre in paired regions will not have maintenance performed at the same time; therefore, workloads balanced across paired regions will be unaffected.

Azure Service Health


Azure Service Health (in public preview at the time of writing) can be used to view problems with Azure services that may impact any of your cloud services. Service Health monitors three types of health event:

  • Service issues – Azure services that are currently experiencing problems
  • Planned maintenance – Any known future maintenance that may affect the availability of your services
  • Health advisories – Changes in services, for example, deprecated features or exceeded quota usage.

Using the Service Heath service, it is not only possible to view in one location any service problems but also setup Health alerts which are a vast improvement on the basic email notification. Service alerts can be configured to:

  • Send Email/SMS/Push/Voice notification
  • Send Webhooks to third party app i.e. ServiceNow or Azure Logic App
  • Send an IT Service Management Ticket
  • Trigger an Automation Runbook.

Creating planned maintenance alerts using Azure Service Health

To demonstrate the alerting capabilities of the Health Service, the rest of this article steps through the process involved in configuring a basic email alert to notify of any planned maintenance events.

1. Login into the Azure portal and select Service Health.
2. Select Health alerts followed by + Create service health alert from the top of the window on the right.


3. In the Edit Alert blade, give the alert a Name, Description, check the subscription is correct and choose a resource group.


4. The next step is to work through the Criteria section choosing which services, regions and types of event alerts should be monitored. For the purpose of this article all services and regions have been checked but only planned maintenance events.


5. Select or create an Action group. (An Action group is a group of actions to be taken, should an event be logged.)


6. Configure the actions to be taken. We are only configuring an email alert, so we first name the action, then chose Email/SMS/Push/Voice from the drop down list.


7. Enter the name and email address of the person who will be sent the notification. Then finally click OK twice to add the activity log alert.


It should now be possible to see the newly created alert, listed in the Health alerts blade.


Should action groups need to be edited or new actions added, either click on Edit this action group from the lower half of the Health alerts blade or browse to the Monitor service and select the Action groups tab.

For more details checkout the Microsoft document site https://docs.microsoft.com/en-us/azure/service-health/service-health-overview 

Azure: Installing GNOME desktop and xRDP to access an Ubuntu 17.10 Server

Microsoft are continually working with different Linux communities to add evermore distributions to the Azure Marketplace. Running Linux machines in the cloud brings with it a number of benefits such as additional stability, security and affordability over that of its Windows counterpart. With Linux now running on two out of every five server instances on Azure, interaction with Linux based systems is becoming an ever increasing occurrence for system administrators.

SSH is the default method when connecting to an Ubuntu server deployed from the Azure Marketplace. For seasoned Linux admin this is fine but for anyone new to the operating system or looking for a quick method of troubleshooting, this style of administration can initially seem daunting or time consuming.

This article shows the steps involved in installing the GNOME desktop and xRDP package on an Ubuntu virtual machine running in Azure. This makes available a more familiar and user friendly remote desktop style connection.

Assumptions

The following assumptions have been made:

    • Ubuntu Server version 17.10 has been deployed from the Azure Marketplace
    • GNOME will be the chosen desktop interface
    • SSH access is available
    • PuTTY will be used as the SSH client
    • Azure Portal access is available.

Installing Gnome Desktop

Although Ubuntu 17.10 “Artful Aardvark” has dropped the Unity 7 desktop, instead switching to GNOME Shell, the Azure Marketplace image is deployed without the desktop package installed. It is worth noting that it’s possible to install xRDP without installing a desktop first, however, the user experience would be similar to that of the terminal experience offered when connecting by an SSH client.

Installing GNOME desktop over a terminal session might sound difficult, although in reality it’s actually a relatively straightforward task. The first step of the process is to remotely connect to the server using an SSH client such as PuTTY and then install the applications from the Official Ubuntu Repository.

Open up PuTTY and using the IP address of the server which can be found on the Overview blade in Azure, configure and establish an SSH connection.


Once the SSH session has been established, go ahead and login to the server.


Before we look to install the desktop, let’s go ahead and update the package list to make sure we have information on the newest versions of the packages and their dependencies. To accomplish this, we run the following command.

sudo apt-get update


We can now begin the desktop install. This is again done by issuing a fairly simple apt-get command from within the terminal session.

sudo apt-get install ubuntu-gnome-desktop


Installing xRDP

Now the desktop has been installed, it’s time to install xRDP. This is an open source remote desktop protocol (RDP) server, which allows you to RDP to your Linux server from a Windows machine. It is capable of accepting connections from rdesktop, freerdp, and remote desktop clients.

To install the package, run the following command.

sudo apt-get install -y xrdp


Configuring  Console Access

Console access is restricted to root by default which essentially means that without making any further changes, connections by anyone else will be dropped. This is obviously not the required user experience, therefore access to the console will need to be configured for all users.

To change access from root only to all users we simply edit the file /etc/X11/Xwrapper.config

This can be done by using an editor such as nano to manually change the line allowed_users=console to allowed_users=anybody.

Alternatively, it can also be updated by running the following command to make the changes.

sudo sed -i 's/allowed_users=console/allowed_users=anybody/' /etc/X11/Xwrapper.config


Adding a Network Security Group rule for RDP traffic

This article is based on an Ubuntu server that has been deployed from the Marketplace. As such, the machine will have been deployed with an NSG that has been configured to manage inbound and outbound traffic. By default, this will only allow port 22 inbound for SSH communication, not 3389 which is required for an RDP connection.

From within the portal, select the servers networking settings before then clicking on “Add inbound port rule


At this point you will be presented with a new blade in which the following settings need to be configured.

  • Service
  • Priority
  • Name
  • Description


As with most things in Azure, it is worth noting that this could also be done through PowerShell or Azure CLI.

Connecting via RDP

Now it’s time to check if the server is configured correctly and allowing RDP connections.

If your connecting from a Windows machine, go ahead and start up the Remote Desktop Connection client. Enter the public IP address of the Ubuntu Server and click on connect.


At this point the xRDP login screen should appear. Go ahead and provide user credentials before selecting OK.


The first time you remotely login to the Ubuntu desktop, you will be presented with the following Authentication Required popup.


Clicking the cancel button a number of times will close the message and allow access to the desktop, although it will return on the next login. To subdue the message permanently, changes to the polkit configuration will need to be made.

To make the required changes, use the following command to create a file called 02-allow-colord.conf in the following location /etc/polkit-1/localauthority.conf.d/ remembering to use admin privileges.

sudo nano /etc/polkit-1/localauthority.conf.d/02-allow-colord.conf


Once nano has created and opened the file for editing, paste the following text into the file, before exiting and saving.

polkit.addRule(function(action, subject) {
if ((action.id == "org.freedesktop.color-manager.create-device" ||
action.id == "org.freedesktop.color-manager.create-profile" ||
action.id == "org.freedesktop.color-manager.delete-device" ||
action.id == "org.freedesktop.color-manager.delete-profile" ||
action.id == "org.freedesktop.color-manager.modify-device" ||
action.id == "org.freedesktop.color-manager.modify-profile") &&
subject.isInGroup("{group}")) {
return polkit.Result.YES;
}
});


If everything has gone to plan, the next time you login, no authentication message should be displayed.


Missing Gnome Desktop Dock

The other thing that you may notice when connecting remotely, is that the Ubuntu Dock is not visible. Having searched around the internet for a fix for this, the best solution I came across, was actually to install the Gnome Tweak tool which in turn then made it possible to enable both the Ubuntu appindicators and Ubuntu dock extensions. For some reason the extensions tab appears to be missing from the default Systems Settings menu.

To install the Gnome Tweak tool, run the following command.

sudo apt-get install gnome-tweak-tool -y

Once installed, simply open the Tweak tool, select the Extensions tab and enable both the appindicators and dock extensions.


Now when connecting to the GNOME desktop, the Dock should be visible on the left hand side of the screen.


That’s it!

In this post we took an Ubuntu server running in Azure, installed the GNOME desktop and xRDP package, then followed up by making the necessary tweaks required for a more streamlined user experience. Connecting to an Ubuntu server by remote desktop connection may not be enabled out of the box but hopefully this article goes to show that it is still an option when administering Linux based machines in the cloud.

 

Azure: Disabling the Windows Firewall on an virtual machine from the portal

The RDP client is one of the most heavily utilised tools in a system administrator’s toolkit. There are alternatives, for example, console access, PowerShell, iLO or in the case of a physical machine the locally connected keyboard and monitor. This is fine for on-premise machines but for machines running in the cloud, most of the alternative methods are not an option and RDP becomes a critical method of connectivity.

Over the past months I have seen an increase in the number of customers that have adjusted the guest Windows OS firewall, inadvertently locking themselves out and making it impossible to manage their Azure virtual machines.


The following article outlines one of the methods I have successfully used when restoring access. This method makes use of the Azure virtual machine Custom Script Extension and a snippet of PowerShell.

1. The first step is to open your preferred PowerShell editor and paste in the following code.

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\services\SharedAccess\Parameters\FirewallPolicy
\DomainProfile' -name "EnableFirewall" -Value 0

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\services\SharedAccess\Parameters\FirewallPolicy\
PublicProfile' -name "EnableFirewall" -Value 0


Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\services\SharedAccess\Parameters\FirewallPolicy\
Standardprofile' -name "EnableFirewall" -Value 0

These commands update local registry values which in turn disables the three firewall profiles on the next machine reboot.

A copy of the file can be downloaded from my GitHub disablefw.ps1.


2. Save the file as <filename>.ps1

3. Now login to the Azure portal and browse to the virtual machine that is having connectivity problems.

4. From the blade of the virtual machine, select Extensions


5. Click the +Add button and select Custom Script Extension from the popup menu.


6. Click on the folder icon to browse to where the <filename>.ps1 file has been stored and after selecting the file, click Open to upload it.


7. The virtual machine extension can now be installed by clicking OK.

NOTE: Additional Arguments are optional and for this task should be left blank.

8. Once the extension is installed, the Azure portal will report that provisioning has been successful.


9. It’s now time to restart the virtual machine before retrying an RDP connection.


This has proven to be very useful to me on a number of occasions, hopefully it will be of assistance to others.

As always, if any mistakes are spotted, feel free to leave me a comment.

Azure: Performance testing Web App using the portal

When deploying web app to Azure, one of the key design considerations is around load planning. Normally this is calculated on expected concurrent connections and resource requirements for the application. One of the great features that Microsoft offer is the ability to configure comprehensive load testing which can give a really quick and simple visual representation of how the deployed web app functioned under predetermined loads.

As with most things in Azure, its possible to author tests in a number of ways including Visual Studio, Visual Studio Team Services (VSTS) and using the Azure Portal. For the purposes of this article, I will be focusing on how quick and simple it is to setup such a load test through the Azure Portal.

Prerequisites

  • Azure subscription
  • Web app to test
  • Team Services account

I’m going to assume that an Azure subscription is in place and that a web app has already been deployed so the only other requirement is that of the Team Services account.

This can be provisioned in one of two ways:

  • Automatically created during the setup of the performance test
  • Manually created in advance

Linking the Team Services account

1. To set the Team Services account, browse to the web app and expand its properties.


2. Next, scroll through the menu and select Performance Test.


3. Finally, click on the Set Account button and either select a Team Services account that already exists or create a new one.


To create a new account, click on Or Create New from the next window.


Configuring the performance test

1. After the Team Services account has been set, the next step is to create a new test. To do this, firstly click on the + NEW button.


2. Next click on Configure test using, choose the test type and make sure the URL is of the website that the test should be run against.

There are two different types of test to choose from:

  • Manual Test
  • Visual Studio Web Test

The manual test allows you to run the performance test against a single URL where as the Visual Studio Web Test makes it possible to incorporating multiple URLs that represent an end-to-end user scenario.

Other settings that can be configured include the number of concurrent users to simulate and the duration the test should run over.


Once created, the test will appear in the list of Recent runs.


Double clicking on the test opens a new blade with a graphical view of its current state and how the test is progressing.


Once the test has completed, the results will be displayed in various formats. The Requests panel shows the total number of requests sent, with the breakdown between successful and failed attempts. By clicking on this box allows you to drill down further into the failure details.


It’s possible from this view to see exactly the type of failure, any context associated with each error and also the number of times each failure occurred.

For more details checkout the Microsoft document site https://docs.microsoft.com/en-us/vsts/load-test/overview

Where has “Desktop Experience Mode” gone from Windows Server 1709?

First of all don’t panic, Windows Server Desktop Experience Mode has not gone for good!

Although for sometime now core has been seen as the preferred version of Windows Server for the enterprise. From experience, most customers will still end up installing the full GUI version.

So why remove it from the latest Windows Server release 1709?

Windows Server, version 1709 is the first release in the new Semi-Annual Channel for Microsoft. The Semi-Annual Channel release is aimed at customers such as those that have a rapid development path or perhaps those acting as hosting companies who wish to keep up with the latest Hyper-V investments. Microsoft plans for Windows Server products in the Semi-Annual Channel to be released twice a year, with each release in this channel being supported for 18 months from the initial release. Microsoft have stated that, most of the features introduced in the Semi-Annual Channel will be rolled up into the next Long-term Servicing Channel release of Windows Server. However, the actual editions, functionality, and supporting content might vary from release to release depending on customer feedback.

Windows Server as we know it with the full Desktop Experience Mode will become the Long Term Service Channel of Windows Server 2016. If you want to stay in this channel, you should continue to install Windows Server 2016, which can be installed in Server Core mode or Server with Desktop Experience Mode.

These changes will call for a more informed discussion during project initiation phases. Choosing the correct OS will be based not only on the need for the latest and greatest features, but also an acceptable upgrade cycle for the business, whether the customer is comfortable supporting Windows Server Core and if the the technology being deployed as part of the proposed solution is supported. For example, Remote Desktop Service (RDS) would not take advantage of the new Semi-Annual Channel where as Hyper-V would.

Both releases will be supported with security updates and non-security updates but feature updates to the LTSC would happen less frequency purely due to its release cycle.

Release channels and installation options

Installation option Semi-Annual Channel (Windows Server) Long-term Servicing Channel (Windows Server 2016)
Nano Server Yes No
Server Core Yes Yes
Server with Desktop No Yes

For much more on this subject, checkout this Microsoft blog:

https://docs.microsoft.com/en-us/windows-server/get-started/semi-annual-channel-overview

Suggestion added to Azure Feedback Forums

Automatically enable MFA for all members of an Azure AD Group.

Add the ability to automatically enable MFA for all members of an Azure AD group as they are added, in addition ask if MFA should be automatically disabled for users being removed. This could be via an option within the users setting of an Azure AD group.

To vote for the suggestion follow the link below.

https://feedback.azure.com/forums/169401-azure-active-directory/suggestions/17380633-automatically-enable-mfa-for-all-members-of-an-azu

Changing the Network Location of a Windows 2012 R2 Server Network Connection

It’s sometimes necessary to manually change the network location configuration of a Windows 2012 R2 Servers network connection. There are two common approaches to this, either by Local Group Policy or PowerShell. In this post I will be stepping through how to implement either method.

Windows classifies networks connections into one of three profiles, each profile configures the server with different firewall settings.

  • Private: Used for computers on a private or home network. This allows you to see computers and devices, while making your computer discoverable.
  • Public: Used for computers on a pubic network such as a coffee shop or internet café. Designed to keep your computer from being visible to other computers around you and to help protect your computer from any malicious software from the Internet.
  • Domain: Used for computers that belong to enterprise network.

By default new network connections are configured with the public profile, however, if ADDS (Active Directory Domain Services) are found on the network, the profile automatically changes to domain.

Changing the Network Location by Local Group Policy

1. Run gpedit.msc to open the Local Group Policy Editor

2. Navigate to Computer Configuration / Windows Settings / Security Settings / Network List Manager Policies and double click the appropriate Network Name

3. From the popup window select the Network Location tab, then select the correct location type

CNL03
4. Click OK and close the Local Group Policy Editor

CNL04
5. Finally checking back in the Network and Sharing Center, the network profile should now display the options chosen in the previous steps.

CNL05

Changing the Network Location by PowerShell

As with most things on Server 2012 it is possible to use PowerShell to change the network category. We first need to list the network connections and make note of the InterfaceIndex associated with the network connection we are looking to reconfigure.

1. Open an elevated PowerShell prompt and run the following CmdLet

Get-NetConnectionProfile

CNL06
2. Make note of the InterfaceIndex for the network connection that requires its location changing. We can then use the following command to change the connections network location type

Set-NetConnectionProfile -InterfaceIndex <ID> -NetworkCategory <Category>

For Example:

Set-NetConnectionProfule -InterfaceIndex 12 -NetworkCategory Private

CNL07
3. To confirm changes have been made, rerun the Get-NetConnectionProfile CmdLet and review the NetworkCategory reflects the change.

CNL08

Azure IaaS: Resize VM disks in Azure

I have recently encountered a couple of situations where it has been necessary to resize disks attached to Azure virtual machines. Generally it has been on machines that have previously been migrated to Azure from their original on-premises infrastructure where storage was more of a premium.

When deploying machines directly in Azure its generally felt that deploying the largest disk possible is the best option. This is because regardless of the disk size, charge is only made for the actual amount of data written to the disk and not the size of the disk itself. The exception to the rule is when using premium storage which is the reverse and charged on the size of the disk and not the amount of data written in it.

In this example the operating system disk is nearly full and needs to be increased in size.

diskresize001
The easiest way to achieve this is to use our old friend PowerShell and the Update-AzureDisk cmdlet.

The first thing that must be done is to work out the disk name of the disk that needs to be resized. This can be done in various ways but generally its easiest to use either the Azure Portal or PowerShell.

Open the Azure portal then select Virtual Machines > Machine Name > All Settings > Disks and locate the disk name.

diskresize002
As mentioned its also possible to use PowerShell to pull back a list of all disks deployed in the current subscription from which their names and other attributes can be gathered. The first step is to connect to Azure and check that we are connected to the correct subscription.

Add-AzureAccount

Get-AzureSubscription -Current

To select an alternative subscription use the following PowerShell command.

Select AzureSubscription -SubscriptionID "Subscription ID"

Now connected to the subscription we require, its possible to search for a list of disks and the virtual machines that they are associated with.

Get-AzureDisk | fl Label, AttachedTo, DiskName

diskresize004
Having collected all the details required, it’s possible to use the next PowerShell command to resize the disk.

Update-AzureDisk -DiskName <diskname> –ResizedSizeInGB <size in GB> –label <labelname>

For Example:

Update-AzureDisk -DiskName TechKB-SVR01-TechKB-SVR01-0-201601281807180110 –ResizedSizeInGB 500 –label sysDrive

diskresize005
NOTE: The size of the updated disk must be between 20-1023GB and the Azure virtual machine must be powered off and in the deallocated state for the command to complete successfully.

diskresize003
After the command runs successfully its possible to view the resized disk in the Azure portal.

diskresize006
Once the disk has been successfully resized, the guest OS needs to be configured to use the additional space now available on the disk.

From within the guest open Disk Manager > Right Click System Volume > Expand Volume and follow the wizard through to add the extra space to the system volume.

diskresize007
Now when browsing in File Explorer the system drives displays the new volume size.

diskresize008