Azure

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.

App Services

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

Clustering

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

Uncategorised

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

Server 2008

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

IaaS

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

 

 

Azure

Microsoft Partner Technology Solutions Professional (P-TSP) for Azure

I’ve recently been nominated and accepted by Microsoft as a Partner Technology Solutions Professional (P-TSP) in Azure!

The Microsoft Partner Technology Solutions Professional Program (P-TSP) is a select group chosen from the various Microsoft partners to act as an extension of the Microsoft’s internal Technology Specialist team. The program is geared to offer real world experience and guidance for Microsoft customers during pre-sales engagements or architectural guidance for enterprise solutions and upgrades.

I’m over the moon to have been put forward for this program and keen to begin integrating more with the guys at Microsoft. I wait to see where this opportunity leads me.

 

Azure

Azure Backup: Changing the Scratch Location

The Azure Backup Agent uses a scratch or cache location to prepare backup data before exporting it to Azure. The recommendation is for this location to be at least 5% of the data backed up to the cloud in size, preferably more. When installing Microsoft Azure Backup calculating the required space is quite simple, however, as backups begin to increase making sure the scratch space is maintained can bring with it problems. i.e. drive space can run out.

In this scenario the scratch location needs relocating. The method documented around moving the scratch location calls for uninstalled and reinstalled the Azure Backup Agent. This can be a pain and requires the passphrase created during the original install, which has of course been saved somewhere safe.

After spending much time researching I came across a couple of articles online outlining a possible alternative. I have since tested the process in my development environment and it does appear to work successfully.

By default, Microsoft Azure Backup creates its scratch folder on the local drive at the following path:

%ProgramFiles%\Microsoft Azure Recovery Services Agent\Scratch\

Changing the default location

1. Open an elevated Command Prompt, then stop the Microsoft Azure Recovery Services Agent service.

net stop obengine

MABAS001
2. Once the service has stopped, copy the scratch folder and data stored within it to its new desired location.

MABAS002
3. Update the following registry entries with the new scratch folder path.

  • [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows Azure Backup\Config\ScratchLocation]

MABAS003
NOTE: Only update this registry key if it already exists otherwise ignore.

  • [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows Azure Backup\Config\CloudBackupProvider\ScratchLocation]

MABAS004
4. Jump back to the elevated Command Prompt, then restart the Microsoft Azure Recovery Services Agent service.

net start obengine

MABAS005
Hopefully this post will be of help to people.

As always, if anyone finds anything within the post to be wrong, please don’t hesitate to let me know so I can adjust accordingly. 🙂

Events

Events: Silversands Azure Seminar at Mercedes Benz World

One of the activities I get involved with from time to time is presenting at customer seminars. Recently I was asked to participate in an Azure round table event hosted at Mercedes Benz World.

Key discussion points included:

  • Azure Site Recovery
  • Azure Backup
  • RemoteApp
  • StorSimple
  • Azure AD Premium
  • Express Route

The feedback from the event was great and two lucky customers were even able to take to the test track.

 

Azure Networking

Test Network Speed and Latency to Azure

Just a quick post to mention one of the many Azure tools out there. This one in particular is for the network admin who have the need or are just interested in checking network connection speed and latencies to the Azure data centres.

TestLat001

http://azurespeed.com comes with a number of useful tests and is ideal during the project planning stage. For example, when planning to migrate a LOB application to Azure, which region would offer the best user experience.

Features include:

Latency Test
This test allows administrators to test network latency to Azure Storage in worldwide data centres.

CDN Test
This is currently unavailable do to attackers.

Upload Speed Test
This test makes it possible to checkout upload speeds to Azure Blob Storage located in different worldwide data centres.

Large File Upload Speed Test
This test allows administrators to test large file uploads to Azure Blob Storage, again in worldwide data centres, with additional upload options.

Download Speed Test
As the title suggests, this test monitors download speeds from different data centres when downloading a 100MB file.

Live Streaming Latency Test
Test latency from remote Azure Media Services live streaming.

Cloud Region Finder
Cloud Region Finder enables you to quickly lookup cloud and region information of application deployment, try it by entering url or ip address now! Currently Azure, AWS, AliCloud are supported.

Traffic Manager Test
Demonstrates the capability’s of Azure Traffic Manger.

Azure Online Tools available.
Additional Azure Online Tools.

A short but hopefully interesting post and well worth a quick visit! 🙂