Microsoft – Page 2

Azure

Using Network Security Groups in Azure to create a DMZ

Posted on 5th August 20159th December 2016

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.

Azure

Updating the Template Image of an Azure RemoteApp Collection

Posted on 28th July 20155th August 2015

Following on from the post Using an Azure Virtual Machine as an Azure RemoteApp Template here is a short article on how to update the template image of an Azure RemoteApp collection.

Scenario:

A new corporate image has been provisioned with the latest Windows updates and a number of new corporate applications. This has been converted into a RemoteApp Template Image which now requires deploying to remote users. How do you update the Template Image of a collection without provisioning a new collection and reconfigure user access?

Updating the Template Image of a RemoteApp collection is a very easy process and can be achieved either via the GUI or PowerShell.

Using the GUI:

Browse to the RemoteApp service and select the collection that requires the Image updating. From the bottom menu click the Update button to initialise the Update RemoteApp collection Template Image wizard.

Once the Update RemoteApp collection Template Image wizard appears, select the new Template Image from the dropdown menu. Then choose how connected users are to be managed during the Image update.

There are two options:

Give users 60 minutes after the update. Selecting this option will send a popup message to all active users as soon as the RemoteApp collection has been updated, telling them to save their work and log off and back on. Any users that fail to follow the notice are automatically logged off after 60 minutes. Users can immediately log back on.
Sign users out immediately. Selecting this option will log off all users automatically without any warning as soon as the RemoteApp collection has been updated with the new template image. Users can immediately log back on. NOTE: If you choose this option, users might lose data.

Finally click on the tick icon to begin the update.

Once the RemoteApp collection has been updated with the new Template Image, open the collection and publish any new applications using the normal processes.

Via PowerShell:

To update the Template Image of a collection, use the following PowerShell command altering the RemoteApp collection name to the one that you wish to update and the name of the new Template Image.

Update-AzureRemoteAppCollection -Name <CollectionName> -ImageName <TemplateImage> -ForceLogoffWhenUpdateComplete

The RemoteApp PowerShell module has recently been updated with lots of new and updated cmdlets offering better administration. Below is a list of the cmdlets available since the latest update.

Basic RemoteApp Collection cmdlets:

New-AzureRemoteAppCollection
Get-AzureRemoteAppCollection
Set-AzureRemoteAppCollection
Update-AzureRemoteAppCollection
Remove-AzureRemoteAppCollection
Add-AzureRemoteAppUser
Get-AzureRemoteAppUser
Remove-AzureRemoteAppUser
Get-AzureRemoteAppSession
Disconnect-AzureRemoteAppSession
Invoke-AzureRemoteAppSessionLogoff
Send-AzureRemoteAppSessionMessage
Get-AzureRemoteAppProgram
Get-AzureRemoteAppStartMenuProgram
Publish-AzureRemoteAppProgram
Unpublish-AzureRemoteAppProgram
Get-AzureRemoteAppCollectionUsageDetails
Get-AzureRemoteAppCollectionUsageSummary
Get-AzureRemoteAppPlan

RemoteApp virtual network cmdlets:

New-AzureRemoteAppVNet
Get-AzureRemoteAppVNet
Set-AzureRemoteAppVNet
Remove-AzureRemoteAppVNet
Get-AzureRemoteAppVpnDevice
Get– AzureRemoteAppVpnDeviceConfigScript
Reset-AzureRemoteAppVpnSharedKey

RemoteApp template image cmdlets:

New-AzureRemoteAppTemplateImage
Get-AzureRemoteAppTemplateImage
Rename-AzureRemoteAppTemplateImage
Remove-AzureRemoteAppTemplateImage

Other RemoteApp cmdlets:

Get-AzureRemoteAppLocation
Get-AzureRemoteAppWorkspace
Set-AzureRemoteAppWorkspace
Get-AzureRemoteAppOperationResult

Hope this was of interest, even if short! 🙂

Azure

Using an Azure Virtual Machine as an Azure RemoteApp Template

Posted on 20th July 20155th August 2015

Provisioning Azure RemoteApp collections requires the administrator to us a preconfigured Server 2012 R2 image. In the same way as with RDS on-premises the image is preinstalled and configured with all of the applications that are to be published to the remote users.

There are three image sources an administrator can currently use when provisioning a collection.

Use one of the preconfigured images Microsoft makes available
Create an image from a virtual machine built on-premises
Create an image from a virtual machine running in Azure

The preconfigured images that Microsoft offer are great for having a quick PoC up and working in a matter of a couple of hours but the recommended option if creating your own is to use an Azure VM.

It goes without saying that plenty of planning should be done when looking to move forward with a production RemoteApp deployment. It is a great Azure service and there are improvements being made all the time but as with everything there are currently some limitations to work with.

For example:

A single user can currently only be assigned to a single collection. Therefore splitting applications such as Office and other LOB applications across multiple collections is not always going to be possible. (I could be wrong but if on-premises RDS is anything to go by, one reason for this could be that a user profile disk can only be used in a single collection and not across multiple.)

As with anything Azure, things change rapidly but as of today, RemoteApp limitations to be aware of during the design phase are:

Resource	Default limit
Collections per user	1
Published apps per collection	100
Paid collections	3 (you can request an increase)
Paid template images	25
Users – basic tier	400 (default)/ 800 (maximum)
Users – standard tier	250 (default)/ 500 (maximum)
Concurrent connections across all collections in a subscription	5000 (you can request an increase)
User data storage (UPD) per user per collection	50 GB
Idle timeout	4 hours
Disconnected timeout	4 hours

** Currently timeouts cannot be managed by GPO or configured by the administrator. They are only managed by the RemoteApp service.

More information about RemoteApp and other Azure Service Limits, Quotas, and Constraints can be found by following this link Azure Subscription and Service Limits, Quotas, and Constraints

Building a RemoteApp Template image in Azure:

There are two steps to creating a RemoteApp Template from an Azure VM.

Create a Azure Virtual Machine image with all preinstalled and configured applications
Import the Virtual Machine image in as an Azure RemoteApp Template

Creating a Azure Virtual Machine image

1. Create an Azure Virtual Machine using the “Windows Server Remote Desktop Session Host” image from the Azure Virtual Machine Gallery. This image contains the Windows Server 2012 R2 operating system with the Remote Desktop Session Host (RD Session Host) role installed and meets all the Azure RemoteApp Template image requirements.

2. Connect to the virtual machine and install and configure all of the applications that you plan to publish later on. (Check the image creation tips at the end of this post.)

3. Now all applications have been installed and configured as required, the image needs to be validated. Because the VM was created using the RDSH image from the Azure Virtual Machine Gallery, we have the luxury of double clicking on the “ValidateRemoteAppImage” shortcut on the desktop. This script validates the virtual machine is ready to be used as a RemoteApp image and checks that it is configured in line with all RemoteApp pre-requisites. If all checks pass successfully, the script even offers the option to run SYSPREP for you!

If the script reports back errors, make sure they are resolved before continuing to SYSPREP the image.

To manually SYSPREP the virtual machine open an elevated command prompt and run the following:

C:\Windows\System32\sysprep\sysprep.exe /generalize /oobe /shutdown

(Do not use the /mode:vm switch even though this is a virtual machine)

4. Once SYSPREP has run and the VM has been shut down, capture the VM as a virtual machine image. To do this, select the correct VM from the list and click the capture button on the bottom menu.

5. When the capture wizard appears, give the image a name, description and check the box to say that SYSPREP has been run on the virtual machine. Doing this will remove the VM once it has been converted to an image. The final step to the process is to click on the tick to begin the import.

Once complete the image will appear under the virtual machine images tab.

Importing the Azure Virtual Machine image in as an Azure RemoteApp Template

1. Browse to the RemoteApp service and the TEMPLATE IMAGES tab at the top. If it’s the first image in the library click on IMPORT OR UPLOAD TEMPALTE IMAGE to open up the next wizard.

If an image already exists, click on the + on the bottom menu bar to begin adding a new image.

AzureRemoteApp009a
2. Select Import an image from your Virtual Machine library (Recommended).

3. Select the Virtual Machine image from the drop down list and check the box to confirm that all the correct steps were taken in creating the virtual machine image.

4. Give the RemoteApp template image a name and location and finish by clicking on the tick button.

When imported, the RemoteApp Template Image is available to the administrator when creating a new RemoteApp collection.

It is possible as mentioned earlier in the post to upload an image that has been created on-premises and I may cover this in a later post, but using an Azure Virtual Machine is a much easier process and Microsoft recommended approach.

The following are a few tips that Microsoft suggest to use when creating the Template image:

Check all applications to be published have start menu shortcuts. This will make publishing the applications much simpler later.
Disable automatic software updates for published applications.
Install the RDSH role before installing applications to ensure that any issues with application compatibility are discovered before the image is uploaded to RemoteApp. (This is already the case with the Azure RDSH gallery image)
Create a local user i.e. sysadmin and add them to the local administrators group and Remote Desktop.
Scheduled tasks do persist after SYSPREP.
Disable automatic software updates for published applications.
Never store data on instances (c:\ drive).

That’s it for this post, its quite a long one but hope people find it useful. 🙂

Azure

ADFS 3.0 Error on Server 2012 R2

Posted on 13th May 201513th May 2015

I have deployed various ADFS servers in production environments and this error is something that until recently I had not seen. I had quickly installed a couple of ADFS servers into my test environment ready for some planned demos when I came across it.

It turned out to be something silly that I had missed, but I thought it would be worth mentioning just in case someone else encountered it.

With ADFS installed and configured, its time to verify the federation service metadata. Normally this looks like the XML file in the screen shot at the end of this post but on this occasion it displayed the following output instead.

Error
AddressThe e-mail address of the userGiven NameThe given name of the username……………..

It turned out that in my haste, I had over looked the following step from the Microsoft ADFS installation guide.

Important
Make sure to configure your browser settings to trust the federation server role by adding your federation service name (for example, https://fs.contoso.com) to the browser’s local intranet zone. This will enable seamless sign-in using Windows Integrated Authentication.
https://technet.microsoft.com/library/c66c7f4b-6b8f-4e44-8331-63fa85f858c2

Recommended Action

Configuring IE to trust the federation server role is a fairly simple task. The first step to the process in to select Tools | Internet Options | Security Tab | Local Intranet.

From this window, click on the Sites button.

Finally, from the next popup click on the Advanced button. Add the federated service name to the list of trusted websites, then close down all the various windows.

NOTE: For the purposes of my test environment I added the whole address space for the techkb.onl domain to the trusted websites. Normally this would have been the individual service name of https://sts.techkb.onl.

After adding the federated service name to the list of trusted Websites, everything looks as it should!

Azure

Exam 70-533: Implementing Microsoft Azure Infrastructure Solutions

Posted on 13th May 201513th May 2015

Its been a while since my last exam, so it was a nice change to have the opportunity to take my Implementing Microsoft Azure Infrastructure Solutions exam today. Thankfully I can say I passed and can now sit back and breathe a sigh of relief!

Spec_Impl_Azure_InfraSol_BW
This exam is targeted at anyone with experience in implementing an infrastructure solution in Microsoft Azure. Professionals that have experience implementing and monitoring cloud and hybrid solutions as well as supporting application lifecycle management.

The areas the exam covers include:

Implement websites
Implement virtual machines
Implement cloud services
Implement storage
Implement an Azure Active Directory
Implement virtual networks

More information on the 70-533 can be found at: https://www.microsoft.com/learning/en-us/exam-70-533.aspx

Azure

Microsoft Azure Site Recovery: Between an on-premises VMM site and Azure – Part Three

Posted on 29th January 201530th January 2015

Here is the final part to my VMM to ASR quick start guide. Its quite a long post with a lot of images, so apologise for that. I have still not covered every little option, but hopefully enough to point anyone in the correct direction.

Items covered in this post include:

Mapping networks
Recovery plans
Failover options.

Mapping networks:

Mapping networks is required in an Azure Site Recovery Vault so when virtual machines fail over to Azure, they know which networks each of their adapters should connect. Its here that a mapping between an on-premise SCVMM logical network is linked to an Azure network. This requires a VPN link or ExpressRoute connection and predefined Azure networks.

Click on the Site Recovery Vault in Azure, then Resources from the top menu and finally on Networks.

From the drop down menus select the Source Location then the Target Location, this will display the various location that can be mapped together. i.e. Azure or an on-premises cluster.

Once a source and target location have been chosen, select a source network, then click Map on the bottom menu. From the dialog box that is displayed, select the network that should be mapped to from Azure.

Once completed, you are able to view the two mapped networks from the main resources tab. If required you can Unmap or Modify the network mapping here also.

Recovery Plans:

Recovery plans are essentially a list of processes that should be carried out during a failover to Azure Site Recovery Services. This can include automated, manual and scripted processes.

To create a Recovery Plan, click on the ASR Vault that requires the Recovery Plan and select Recovery Plans from the top menu. If this is the first recovery plan of the recovery vault, you will be prompted with the window below. Alternatively you can select the +NEW button from the bottom menu bar.

On the first page of the Create Recovery Plan wizard, fill in the required details, Name, Source Type, Source, and Target then click on the arrow to continue to the second page.

From the second page of the wizard, select the virtual machines that the Recovery Plan will apply to and then finalise the wizard by clicking on the small tick button.

Once created, the recovery plan is listed under the Recovery Plans tab of the ASR Vault. By clicking on the recovery plan, it can be configured further.

From here its possible to add more virtual machines to the current group, additional groups of virtual machines. Each groups of resources can have assigned to it a different set of processes which will be run against them during the processing of this recovery plan. This allows the administrator to run different tasks against different resources in the same recovery plan. Form here it is also possible to assign scripts as part of the process and manual actions. Manual actions can be used to flag up manual processes during a failover, for example to remind the engineer initiating the failover to patch in a network router or make any DNS changes that might be required.

Failover:

There are two main failover options in an Azure Site Recovery Vault.

Test Failover: This option makes it possible to test a single machine failover or a complete recovery plan failover, whilst isolating the resources from the relevant networks.
Failover: This option initiates a full DR failover based on a single machine or full recovery plan failover. It also offers two different scenarios, planned or unplanned failover.

To initiate a Test Failover, browse to the protected machine or recovery plan that you wish to test. Then from the bottom ribbon select Test Failover.

After initiating a Test Failover, it will be necessary to select the network that the cloned resources will be connected to. Generally for most testing its acceptable to select None.

The status bar at the bottom of the Azure portal will report that the process is underway.

Once the test failover has deployed the relevant machines, the job will stop and require manual attention to confirm that things have gone as expected.

The test failover job properties show the virtual machine, source server, source cloud and target, in this case Azure.

At this point in the test failover, the cloned resources should have been deployed to the Virtual Machine area of the Azure Portal.

NOTE: If you want to RDP into the VM after failover occurs, you’ll need to open up port 3389 under ENDPOINTS. This can be found by clicking on the cloned machine and then selecting Endpoints from the top ribbon.

Once port 3389 is open, its now possible to connect via RDP. If opening this port up is not an option, the other way is to connect the test failover to a different network at the beginning of the process. It will need to be a different network to the one its currently configured with.

Once all testing has been completed, the test failover process will need to be completed. Jump back to the waiting job and click Complete Test. This will display a dialog window which requires confirmation of the test end by checking the ‘The test failover is complete. Clean up test environment.’ box and clicking the tick.

The test failover will then continue to clean up the environment.

Once finished, the latest failover test is recorded along side the protected item in the recovery services vault.

Initiating a full Failover is done from the same location a Test Failover. Browse to the protected machine or recovery plan that you wish to failover and then from the bottom ribbon select Failover.

There are two main options when initiating a failover:

Planned Failover

Selecting a planned failover displays the following dialog box which requires the tick to be selected to confirm the action.

The first part of the planned failover is to shutdown on-premises resources, before syncing latest’s changes to Azure. The final step is to then deploy the resources into Azure and start them up.

Unplanned failover

When choosing to run an unplanned failover, there are a further two options.

on-premises is still available:

Click on the unplanned failover option, but then tick the small box to ‘Shut down virtual machines and synchronise the latest data‘.

In the event the on-premises resources are still available, an unplanned failover will follow the same process as the planned and attempt to cleanly shutdown the on-premises resources before syncing data and starting up the Azure clones. However, if the sync fails, the failover will continue regardless using the latest replica point.

Once the on-premises resource has been stopped and the data has been synced, a final commit is required before the process is complete.

At this point it is possible to change the recovery point that should be failover to if the Latest is not the one required.

on-premises is offline:

Click on the unplanned failover option, but then DO NOT tick the small box to ‘Shut down virtual machines and synchronise the latest data‘.

In the event that the on-premises resources are offline, the option to showdown and synchronise data can be left unchecked and the failover process will continue, booting the resources from the latest replica points. This will cause a slightly older version of the resource to boot and cause a potential data lose situation.

Fail back to on-premises:

Once failed over to Azure, its is then possible to failover back to on-premises using the same processes. i.e. selecting the machine or the recovery plan, selecting planned or unplanned failover then completing the popup dialogue box.

That’s it! Hope its of some help.

Microsoft Azure Site Recovery: Between an on-premises VMM site and Azure – Part One

Microsoft Azure Site Recovery: Between an on-premises VMM site and Azure – Part Two

Microsoft Azure Site Recovery: Between an on-premises VMM site and Azure – Part Three

Azure

Microsoft Azure Site Recovery: Between an on-premises VMM site and Azure – Part Two

Posted on 9th January 201529th January 2015

Here is part two of my VMM to Azure quick guide. In part one, the Hyper-V and VMM servers had the required agents installed and the VMM server was registered with the Azure Site Recovery Vault.

In this part I’m going to cover:

Configuring cloud protection
Managing virtual machine protection
Changing the hardware sizing of virtual machines

Configuring cloud protection:

During the installation of the VMM agent, if the Sync cloud meta data to site recovery portal option is checked, there should be a list of your on-premises clouds appear in Azure. This is found under the Protected Items tab of the Site Recovery Vault that you have registered the VMM Server with.

If you didn’t or there where problems during the agent install, you will need to open SCVMM, select a cloud you wish to protect, right click and open the properties tab and finally check the box ‘Send configuration data about this cloud to the Windows Azure Hyper-V Recovery Manager’

Once the clouds appear, select the cloud you wish to protect, click on Configure Protection Settings, select Azure as the target, configure any other cloud settings then click SAVE on the bottom menu bar.

Setting that you may wish to adjust include

Copy Frequency: 30 Seconds | 5 Minutes | 15 Minutes
Retain Recovery Points For (Hours): 0 – 24
Frequency of application consistent snapshots: Never – 12 Hours

Once the configuration setting have saved, the cloud is protected and this is shown in the Azure Portal.

Managing virtual machine protection

To protect virtual machines, they must reside in one of the protected clouds. Click on the protected cloud to open it, then either click on Enable Protection if you are adding the first virtual machine for protection or click on the + Add virtual Machine button on the bottom menu.

Select the virtual machine you wish to protect and if its running Windows or Linux and then click the tick to begin protection of the virtual machine.

There are multiple ways to enable protection on a virtual machine, another way is by setting it on a virtual machine within VMM. Browse in VMM to the virtual machine you wish to protect, select the virtual machine and then click the Manage Protection button on the top ribbon. As with most things Microsoft there are various ways to achieve the same thing and in VMM is no exception, with various locations available to enable protection.

Once the machine has been enabled for protection, the virtual machine will begin to sync with the Azure Site Recovery Vault.

Changing the hardware sizing of virtual machines

Once the the virtual machine has replicated to ASR, its possible to change some of the hardware details of the Azure clone. It maybe that in a DR scenario, as long as the resource is able to continue to run in the cloud, performance is not so much of a problem as that of the cost to do so. Azure offers the ability to select the size of Azure machine you wish it to run on, depending on processor and RAM requirements.

To do this, open the protected cloud which the protected virtual machine resides in, then click on the virtual machine to display the Source and target properties.

It is from here the machine size can be changed.

That’s the end of this part of the post, in part three I hope to cover:

Mapping networks
Recovery plans
Failover options.

Microsoft Azure Site Recovery: Between an on-premises VMM site and Azure – Part One

Microsoft Azure Site Recovery: Between an on-premises VMM site and Azure – Part Two

Microsoft Azure Site Recovery: Between an on-premises VMM site and Azure – Part Three

Azure

Azure G-Series VM Sizes availability

Posted on 8th January 20158th January 2015

Today, Microsoft announced amongst other things, the General Availability release of a new series of VM sizes for Azure Virtual Machines called the G-series. G-series sizes provide the most memory, the highest processing power and the largest amount of local SSD of any Virtual Machine size currently available in the public cloud.

To read more on this check out this Azure blog announcement Azure is now bigger, faster, more open, and more secure

The new sizes are defined as follows:

VM Size	Cores	RAM (in GiB)*	Local SSD Storage (in GB)*	Persistent Data Disks Max
Standard_G1	2	28	412	4
Standard_G2	4	56	824	8
Standard_G3	8	112	1,649	16
Standard_G4	16	224	3,298	32
Standard_G5	32	448	6,596	64

*In the table above GB is 1000³and GiB is 1024³

NOTE: As of today, these Virtual Machine sizes are available in West US. Microsoft are working to add support for additional regions.

Azure

Microsoft Azure Site Recovery: Between an on-premises VMM site and Azure – Part One

Posted on 8th January 201523rd February 2015

I have recently seen an increase in the interest from clients wishing to invest in DR and Backup to the cloud. Azure Site Recovery Services has many offerings for various scenarios, with additional options appearing all the time. I have discussed Azure Backup Vault in previous posts and no doubt will touch on it again in the future, but today I have chosen to look at DR and Azure Site Recovery.

So what is ASR?

‘Azure Site Recovery helps you to protect important applications by coordinating the replication and recovery of physical or virtual machines. You can replicate to your own datacenter, to a hosting service provider, or even to Azure to avoid the expense and complexity of building and managing your own secondary location.’ Microsoft

Essentially, Microsoft Azure Site Recovery offers the ability to simplify and automate DR between two on-premise site or between on-premise and Azure.

As I write this the options are:

Microsoft are developing ASR rapidly and additional functionality is always appearing, with much to come in Q1 and Q2 of 2015.

For this particular post I will be focusing on the Between an on-premises VMM site and Azure option.

Requirements

An Azure Subscription
System Center Virtual Machine Manager 2012 R2
Windows Server 2012 R2 Hyper-V – used as VM host
Fixed disk .VHD or .VHDX (Generation 1 only VMs)
Guest OS Windows Server 2008 or later or Linux: Centos, openSUSE, Ubuntu

More details on requirements and planning are located here: https://msdn.microsoft.com/en-us/library/dn469074.aspx

Setting Up the Azure Site Recovery Vault:

The first step to configuring DR between an on-premises VMM site and Azure is to create a Site Recovery Vault. To do this, open the Azure Portal and select the Recovery Services tab on the left menu.

Next click + NEW at the bottom of the screen which opens the window required to create a Site Recovery Vault and a Backup Vault. Select Site Recovery Vault, then give the vault a name and select the region where the data should be stored.

A full list of Regions can be found at https://azure.microsoft.com/en-us/regions/

After the job has completed, the new Site Recovery Vault appears as Active.

Configuring the Hyper-V and VMM servers:

Now the ASR Vault has been created, the next step is to configure the local Hyper-V and VMM servers. Click on the new ASR Vault to open its Dashboard.

Download the ASR Provider and Registration key. Install the ASR Provider on the VMM server and register against the ASR Vault by using the registration key.

NOTE: If you are running VMM in HA, the first step is to install the ASR provider on the active node, then register the server. Then secondly install the ASR provider on the passive node.

Return back to the Dashboard and then select to Add an Azure Storage Account.

Give the storage account a name (lowercase case and numbers only). Select the location of the storage account and the chosen level of redundancy.

Option	Redundancy	Comments
Locally Redundant	3 copies replicated within a single datacentre	CheapestProtects against hardware failureDoes not protect against loss of facility or region
Zone-Redundant	3 copies replicated between 2 or 3 datacentres in a single region	Protects against hardware failureProtect against loss of facilityDoes not protect against loss of region
Geo-Redundant	6 copies replicated 3 times within the primary region and 3 times in a secondary region	Maximum durabilityProtects against hardware, facility and regional lossRecommended as default
Read-Access Geo-Redundant	Same as Geo-Redundant, additionally grants Read-Access in the secondary region in the event of primary region loss	Maximum durability and availabilityMost expensive

Once the storage account has been successfully created, it will appear under the Storage tab of the Azure Portal.

The final step is to download the Azure Recovery Services Agent and install on all hyper-V hosts. When installing the agent, the agent is smart enough to detect if there is a previous version present and attempt to upgrade it.

This is how the Azure Recovery Services Agent looks when its upgrading a previous version.

Now the Azure Recovery Services Agent has been installed on all the Hyper-V servers, this seems a natural point to end this first post. In summary, the on-premises Hyper-V and VMM servers have been configured and registered to the created Azure Site Recovery Vault. Everything is now in place to begin configuring the protection of on-premises clouds and resources.

The next part of this post will include:

Configuring cloud protection
Managing virtual machine protection
Changing the hardware sizing of virtual machines
Mapping networks
Recovery plans
Failover options.

Microsoft Azure Site Recovery: Between an on-premises VMM site and Azure – Part One

Microsoft Azure Site Recovery: Between an on-premises VMM site and Azure – Part Two

Microsoft Azure Site Recovery: Between an on-premises VMM site and Azure – Part Three

Azure

Renaming your Microsoft Azure Subscription

Posted on 2nd December 201423rd February 2015

If you’re like me, since creating your Azure subscription the usage for it has changed and the name you originally gave the subscription does not best describe it.

Here is a quick post on how to rename your Azure subscription.

As with most things Microsoft, there are a number of ways of navigating around and accomplishing the same thing, here is one of them. From within your Azure management portal, click on Subscriptions on the top bar, this will drop down a menu from which you can select Manage your account. You will be required to input your username and password but this will then take you to Azure usage and billing.

Once inside Azure usage and billing, click on the subscription you wish to rename. In this example MDCAD MSDN. This will open the main summary page which will display the billing overview and breakdown for the chosen subscription.

On the right side of the Summary page you will see a small menu, (Image below) from here select Edit subscription details.

In the EDIT YOUR SUBSCRIPTION window, change the Subscription name to what is now required, then click on the tick to complete your changes.

Once all the changes have been made, your renamed subscription will be reflected in the usage and billing portal.

Back inside your Azure portal, the subscription name change will also be reflected.