Azure | Hyper-V | SCVMM | RDS | DPM Technical Blog – Michael Coutanche
On Wednesday 12th December, I will be co-hosting alongside James Boother (Coeo) and Microsoft for our final webinar of the year ‘Beyond SQL Server 2008’
The webinar will take you through the ins and outs of unsupported platforms and how to modernise following the end of Server 2008 and SQL Server 2008 support.
Register here: https://hubs.ly/H0fMnBp0
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.
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.
The following assumptions have been made:
NOTE: To check what version of PowerShell is installed and for help on upgrading it if required, see Install Azure PowerShell module.
1. The first thing we need to do is get the application gateway object and store it as a variable
|
1 2 3 |
$appgw = Get-AzureRmApplicationGateway ` -Name appgw-name ` -ResourceGroupName appgw-rg |
2. Get the existing HTTPS listener
|
1 2 3 |
$myHTTPSListener = Get-AzureRmApplicationGatewayHttpListener ` -Name appGatewayHttpsListener ` -ApplicationGateway $appgw |
3. Get the existing HTTP listener
|
1 2 3 |
$myHTTPListener = Get-AzureRmApplicationGatewayHttpListener ` -Name appGatewayHttpListener ` -ApplicationGateway $appgw |
4. Now create a redirection configuration using a permanent redirect and targeting the existing listener
|
1 2 3 4 5 6 7 |
Add-AzureRmApplicationGatewayRedirectConfiguration ` -Name redirectHttptoHttps ` -RedirectType Permanent ` -TargetListener $myHTTPSListener ` -IncludePath $true ` -IncludeQueryString $true ` -ApplicationGateway $appgw |
5. Get the newly created redirect configuration
|
1 2 3 |
$redirectconfig = Get-AzureRmApplicationGatewayRedirectConfiguration ` -Name redirectHttptoHttps ` -ApplicationGateway $appgw |
6. Add a new rule to handle the redirect from the HTTP listener
|
1 2 3 4 5 6 |
Add-AzureRmApplicationGatewayRequestRoutingRule ` -Name rule2 ` -RuleType Basic ` -HttpListener $myHTTPListener ` -RedirectConfiguration $redirectconfig ` -ApplicationGateway $appgw |
7. Finally, update the application gateway
|
1 2 |
Set-AzureRmApplicationGateway ` -ApplicationGateway $appgw |
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
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 |
# Get the application gateway $appgw = Get-AzureRmApplicationGateway ` -Name appgw-name ` -ResourceGroupName appgw-rg # Get the existing HTTPS listener $myHTTPSListener = Get-AzureRmApplicationGatewayHttpListener ` -Name appGatewayHttpsListener ` -ApplicationGateway $appgw # Get the HTTP listener $myHTTPListener = Get-AzureRmApplicationGatewayHttpListener ` -Name appGatewayHttpListener ` -ApplicationGateway $appgw # Add a redirection configuration using a permanent redirect and targeting the existing listener Add-AzureRmApplicationGatewayRedirectConfiguration ` -Name redirectHttptoHttps ` -RedirectType Permanent ` -TargetListener $myHTTPSListener ` -IncludePath $true ` -IncludeQueryString $true ` -ApplicationGateway $appgw # Get the redirect configuration $redirectconfig = Get-AzureRmApplicationGatewayRedirectConfiguration ` -Name redirectHttptoHttps ` -ApplicationGateway $appgw # Add a new rule to handle the redirect and use the new listener Add-AzureRmApplicationGatewayRequestRoutingRule ` -Name rule2 ` -RuleType Basic ` -HttpListener $myHTTPListener ` -RedirectConfiguration $redirectconfig ` -ApplicationGateway $appgw # Update the application gateway Set-AzureRmApplicationGateway ` -ApplicationGateway $appgw |
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/
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:
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 (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:
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:
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
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.
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:
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.
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:
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
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.
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.
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
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
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.
After the command runs successfully its possible to view the resized disk in the Azure portal.
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.
Now when browsing in File Explorer the system drives displays the new volume size.
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.
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! 🙂
As mentioned in my previous post here Microsoft have added the ability to backup additional workloads such as SQL, Exchange, Hyper-V and SharePoint to the cloud. Essentially this version of Microsoft Azure Backup is actually nothing more than a rebranded version of System Center Data Protection Manager with the backup to tape option replaced with the cloud and the ability to integrate with System Center removed. However, where no separate license is required, I believe this now opens the door to many new enterprises and I’m sure it will become a very favourable cloud backup solution.
In this post I will step through the process of configuring a Microsoft Azure Backup Vault, installing Microsoft Azure Backup and registering it with the previously created vault.
Apart from the extra application workloads, the main difference Azure Backup has to the Azure backup agent is the fact that as with DPM, it requires its own server to run on. This server can be configured as:
NOTE: The server must NOT have SCDPM or the SCDPM agent installed, nor should the Microsoft Azure Backup agent be installed and registered with an Azure Backup Vault.
Hardware Requirements
Additional Prerequisites
Create a Microsoft Azure Backup Vault
Once a base server has been prepared, the next step is to preconfigure the Azure Backup Vault. The Microsoft Azure Backup Serer will be registered with the vault later.
To create an Azure Backup Vault, firstly browse to https://manage.windowsazure.com and sign in to the Azure Portal with your credentials.
Scroll down the left hand menu and click on the Recovery Services tab.
In the main window click on CREATE A NEW VAULT.
Select Backup Vault > Quick Create before giving the backup vault a Name and Region and clicking the check to create the Backup Vault. The Region will be the location in which the data is stored, choosing the correct location can help reduce network latency when backup up data to Azure.
Once the Backup Vault has successfully been created it will appear in the list of recovery services resources as Active.
Once items have been archived to the Backup Vault its not possible to change the replication type, so its at this point we need to decided how this should be configured.
By default a Backup Vault is configured with Geo-Redundant Storage, to change this click on CONFIGURE before changing the replication option and clicking SAVE to complete the change.
Installing Microsoft Azure Backup Server
Before we can begin the install of Microsoft Azure Backup server we need to first download the installation software for Azure Backup and also the Backup Vault credentials which are needed for registering the server with the Backup Vault. Both downloads can be found on the Quick Start tab of the Backup Vault.
Microsoft Azure Backup can also be downloaded directly from here
Microsoft Azure Backup comes split up into six separate files, five .bin files and single .exe. Download them all to the same location and then run MicrosoftAzureBackupInstaller.exe, this will begin the setup wizard.
On the first screen click Next to continue.
On the next screen choose a location for setup to extract its files or leave the default. When happy with the location, click Next.
Click on Extract to begin extracting the install files.
By default, Execute setup.exe is checked, leave this checked and click Finish if you wish to continue with the installation. Otherwise, uncheck the option and click Finish.
On the Microsoft Azure Backup splash screen select to install Microsoft Azure Backup.
On the Welcome page, click Next.
On the next page click on the Check button to confirm the server meets software and hardware requirements. Resolve any issues that are raised before continuing by clicking the Next button.
Choose whether to use a new or existing instance of SQL then click Check and Install to begin prerequisite checks and install any missing Windows components.
As long as all prerequisites mentioned at the beginning of the post are installed, the only warning message that should be displayed is to warn the SISFilter has been installed and the server requires a reboot.
Reboot the server and then restart the installer.
Once the server has been rebooted, click Check Again and once the computer meets all software and hardware requirements, click Next.
The next step is to choose the file locations for the program files, database files and scratch folder, then click Next.
NOTE: As mentioned in the prerequisites, the scratch location must have free space of at least 5% of the data backed up to the cloud.
Enter a strong password for the restricted local user accounts the wizard creates, then click Next.
Choose whether or not to use Microsoft Update, then click Next.
Review configuration and click Install to begin installation.
The next stage of the installation installs the Microsoft Azure Recovery Service Agent. If the server connects to the internet by a proxy, this is where the proxy settings need to be added.
Click Next.
By clicking Install, setup checks for all prerequisites, installs any that are missing and completes the installation of the Microsoft Azure Recovery Services Agent.
Click Next.
After the Microsoft Azure Recovery Services Agent has been installed, the next step is to register this server with the Microsoft Azure Backup Vault that was configured at the beginning of this process. To do this browse to the credentials file downloaded from the Backup Vault, then click Next.
Enter a passphrase or click the Generate Passphrase button to automatically generate a passphrase. The passphrase requires the minimum of 16 characters. The passphrase should also be saved somewhere safe, if lost it will not be possible to recover data from the cloud or connect other Microsoft Backup Servers to the online replicas.
Click Next to continue.
Once the connection has been created to the Azure Backup Vault, the installer continues with the installation of SQL Server, SQL Tools and Microsoft Azure Backup.
Once installation has complete, click Close.
At this point in the setup process, Microsoft Azure Backup has been installed and associated with the cloud storage in the selected Microsoft Azure Backup Vault. However, before its possible to configure the first protection group and begin backing up data, local storage needs to be added. To do this, double click on the Microsoft Azure Backup icon on the server desktop to open the application.
Click on Management.
Click on Disks, then on Add.
Select the disk that will be added to the storage pool, click Add then OK.
If everything has gone correctly, the disk will appear in the list of disks available to the storage pool.
Microsoft Azure Backup is now installed and configured with local and cloud storage. It is now ready to begin configuring protection groups and start to backup data.
That’s it for this post, in future articles I plan to cover more Azure Backup processes so don’t forget to check back!
With more businesses becoming reliant on the cloud and on-premises datacenters being extended to Azure, ExpressRoute is becoming ever more popular. For customers that already have in place a site-to-site VPN, one of the first things to do after the ExpressRoute circuit has been previsioned is to switch the virtual network connection from a site-to-site VPN to the ExpressRoute circuit.
The following article works through the various steps involved in this process, including:
NOTE: Migrating an existing virtual network from a site-to-site VPN to an ExpressRoute circuit will cause a short amount of lost connectivity between your on-premises network and your virtual network.
If like me you have access to multiple Azure subscriptions, the first thing to do is check you are in the right one. Using the cmdlet below we can pull back the details for the subscription that we are currently working in.
Get-AzureSubscription -Current
To change subscriptions if required use:
Select-AzureSubscription -SubscriptionID "Subscription ID"
Once working in the correct subscription it is time to import the ExpressRoute PowerShell module. The module doesn’t load by default when PowerShell is run but it is found on the local drive and was installed by the Azure PowerShell installer.
To import the module run:
Import-Module 'C:\Program Files (x86)\Microsoft SDKs\Azure\PowerShell\ServiceManagement\Azure\Azure.psd1'
Import-Module 'C:\Program Files (x86)\Microsoft SDKs\Azure\PowerShell\ServiceManagement\Azure\ExpressRoute\ExpressRoute.psd1'
Checking the status of the ExpressRoute circuit
It is now possible to check that the ExpressRoute circuit has been provisioned correctly and is in the correct state. Use the Get-AzureDedicatedCircuit cmdlet to pull back information about the current circuits.
Before its possible to assign this circuit to a virtual network we need to make sure that the ServiceProviderProvisioningState is Provisioned and that the Status is Enabled. Once this is the case the circuit is ready!
Updating the Virtual Network configuration
The first thing we need to do to is update the configuration of the virtual network gateway. To do this we need to first remove the current gateway which will then allow us to make configuration changes. This can be done via the portal and clicking on the Delete Gateway button or by using the Remove-AzureVNETGateway PowerShell cmdlet.
The next step in configuring the virtual network involves resizing the existing gateway subnet. The site-to-site gateway supports a maximum size of a /29 subnet whereas the ExpressRoute gateway supports a minimum gateway subnet size of /28. As always this can be done either in the management portal or via PowerShell.
After resizing the gateway subnet but before recreating a new gateway, we need to configure the virtual network for an ExpressRoute connection. To do this open the virtual network configuration tab and check the Use ExpressRoute checkbox in the management portal then click save.
The final step in upgrading the virtual network configuration is to create a new Gateway. From within the management portal click the CREATE GATEWAY button to recreate the gateway.
Once the gateway has completed provisioning, the final stage is to link the virtual network to your existing ExpressRoute circuit.
Linking ExpressRoute to the Virtual Network
At this point we can double check the ExpressRoute circuit is still in the correct state, then finally link the circuit with the virtual network.
Get-AzureDedicatedCircuit
$Vnet = "VirtualNetwork-1"
$ServiceKey = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
New-AzureDedicatedCircuitLink -ServiceKey $ServiceKey -VNetName $Vnet
A full listing of ExpressRoute PowerShell Cmdlets can be found in this Microsoft article Azure ExpressRoute PowerShell Cmdlets
That’s it for this post, hope its of some help 🙂
If you have been working with O365 for some time, one thing you would have come across would be the ability to add your company as the Partner of Record for your customers O365 tenancy. This setting has made it across to Azure and it’s now possible to add yourself as Partner of Record within an Azure subscription. As you would imagine, it’s very straightforward to make this change.
1. The first step is to browse to https://account.windowsazure.com/ and login.
2. Then click on the Subscriptions tab followed by the subscription that you wish to update the settings.
3. From here you will see the following menu displayed down the right hand side of the page.
4. Select Partner Information from the menu, this will popup the Partner Information dialog box.
5. Type your MPN ID into the Microsoft Partners ID box and click on the check to finalise the update.
I would recommend updating this wherever possible, however, although there is no impact on support or services that your customer get from Microsoft, it’s important to make sure they are happy for you to be the Partner of Record for their subscription. Longer term not only will it allow you to keep up to date with any communications between Microsoft and your customer but there are plans moving forward for Microsoft to use this to allow your customers Azure consumption to count towards competencies and so forth.
NOTE: This is being rolled out gradually and you may find the option is currently greyed out or missing in older subscriptions.
More and more enterprises are extending their datacentre to the cloud and making use of these resources to deploy ever more complex solutions. As with on-premises infrastructure, it is quite often necessary to setup up different security zones in the cloud i.e. Trusted and DMZ.
On-premises we tend to deploy firewall appliances which are used to achieve this segmented networking infrastructure. However when deploying infrastructure to Azure, this option is not available to administrators. Microsoft Azure allows administrators to control the traffic in subnets using the Network Security Group (NSG) feature. Using an NSG makes it possible to create a subnet with restricted access from the other Azure subnets and also on-premises network.
Network security groups give the ability to configure rules and control inbound and outbound network traffic that can then be assigned to a single VM or a whole subnet and all the VMs within it.
The main reason I have used NSGs has been when deploying ADFS to Azure. A typical deployment has two domain controllers, two ADFS servers and single ADSync server in a trusted subnet and then two WAP servers in the DMZ subnet.
For example:
Configuring Network Security Groups is currently via Azure PowerShell as shown below.
Deploying a Network Security Group:
The first thing to do when deploying a Network Security Group is to create a default NSG. Use the PowerShell command below giving it a name, location and a label for the NSG.
New-AzureNetworkSecurityGroup -Name "WAP-HTTPS" -Location "North Europe" -Label "Security group for DMZ Subnet"
Once the NSG has been created we can display the default rules that have been associated with it.
View the NSG details:
Get-AzureNetworkSecurityGroup -Name "WAP-HTTPS" -Detailed
The next step is to add any inbound rules to the NSG that we require. That is inbound traffic to the subnet that the NSG will be assigned to later. In this example it is inbound traffic to the subnet that will be used as the DMZ and house the WAP servers. These rules are not limited to allow but also deny rules.
Create Inbound NSG Rules:
Get-AzureNetworkSecurityGroup -Name "WAP-HTTPS" | Set-AzureNetworkSecurityRule -Name "Allow Inbound RDP from ALL Internal Networks" -Type Inbound -Priority 101 -Action Allow -SourceAddressPrefix 'VIRTUAL_NETWORK' -SourcePortRange '*' -DestinationAddressPrefix 'VIRTUAL_NETWORK' -DestinationPortRange '3389' -Protocol TCP
Get-AzureNetworkSecurityGroup -Name "WAP-HTTPS" | Set-AzureNetworkSecurityRule -Name "Allow Inbound HTTPS from Internet" -Type Inbound -Priority 110 -Action Allow -SourceAddressPrefix 'INTERNET' -SourcePortRange '*' -DestinationAddressPrefix "DMZ Subnet" -DestinationPortRange '443' -Protocol TCP
Get-AzureNetworkSecurityGroup -Name "WAP-HTTPS" | Set-AzureNetworkSecurityRule -Name "Allow Inbound RDP from Internet" -Type Inbound -Priority 111 -Action Allow -SourceAddressPrefix 'INTERNET' -SourcePortRange '*' -DestinationAddressPrefix "DMZ Subnet" -DestinationPortRange '3389' -Protocol TCP
Get-AzureNetworkSecurityGroup -Name "WAP-HTTPS" | Set-AzureNetworkSecurityRule -Name "Deny Inbound traffic to Trusted Subnet" -Type Inbound -Priority 200 -Action Deny -SourceAddressPrefix 'VIRTUAL_NETWORK' -SourcePortRange '*' -DestinationAddressPrefix 'VIRTUAL_NETWORK' -DestinationPortRange '*' -Protocol '*'
Once all the inbound rules have been created its time to add outbound rules. Again this is outbound traffic from the subnet being used as the DMZ in this example.
Create Outbound Rules:
Get-AzureNetworkSecurityGroup -Name "WAP-HTTPS" | Set-AzureNetworkSecurityRule -Name "Allow Outbound HTTPS from DMZ Subnet" -Type Outbound -Priority 100 -Action Allow -SourceAddressPrefix 'VIRTUAL_NETWORK' -SourcePortRange '*' -DestinationAddressPrefix 'VIRTUAL_NETWORK' -DestinationPortRange '443' -Protocol TCP
Get-AzureNetworkSecurityGroup -Name "WAP-HTTPS" | Set-AzureNetworkSecurityRule -Name "Deny Outbound traffic from DMZ Subnet" -Type Outbound -Priority 200 -Action Deny -SourceAddressPrefix 'VIRTUAL_NETWORK' -SourcePortRange '*' -DestinationAddressPrefix 'VIRTUAL_NETWORK' -DestinationPortRange '*' -Protocol '*'
Once again at this stage we can use the ‘Get-AzureNetworkSecurityGroup’ cmdlet with the -Detailed switch as above to get a screen output of the rules now configured in the NSG.
The final step to the configuration is to assign the NSG to our DMZ subnet. This subnet is where the inbound and outbound rules will apply once the NSG has bound to the subnet.
Add the SG to the backend subnet:
Get-AzureNetworkSecurityGroup -Name "WAP-HTTPS" | Set-AzureNetworkSecurityGroupToSubnet -VirtualNetworkName "vNET" -SubnetName "DMZ Subnet"
NOTE: When making changes to an NSG, if they don’t appear to take effect immediately, allow plenty of time before making any further changes. It’s my experience that people can change good configuration, assuming what they have configured is not working.