Search This Blog

Monday, June 30, 2014

Dimmed CONNECT button: Unable to RDP into Virtual Machine When Test Azure Site Recovery Manager

 

Problem:-

  • CONNECT button is dimmed and unable to rdp into virtual machine.

Scenario:-

  • Setup Azure Site Recovery – On Premise to Azure (currently under preview)
  • Test Failover or
  • Perform Planned Failover or
  • Perform UnPlanned Failover

Virtual Machine created from the Azure storage will encountered “CONNECT” button dimmed.

9

Solution:-

A VM created using Azure Site Recovery do not came with endpoint configure. Guess what? It’s blank. So you need to manually

1. Add a new endpoint

2. Enable RDP setting inside the virtual machine (on primary VM on-premise)

After a new has been created, you need to manually add a new endpoint. Inside the VM,

  • Click Endpoint tab
  • Click +ADD

6

  • Click Add a Stand Alone Endpoint

7

Specify –

  • Name -Remote Desktop
  • Protocol – TCP
  • Public Port – Other port than 3389
  • Private Port - 3389

8

Click OK. That should do the trick and now CONNECT button is enabled.

Microsoft Azure Site Recovery : On-Premise to Microsoft Azure Part 2

Continue from our previous post, we have talked about the requirement and preparation that need to get ready for setting up Azure Site Recovery.

In this post, we will proceed to discuss on configure cloud protection and enable VM replication to Azure.

Cloud Configuration

Cloud

Once VMM has synced cloud setting, you can view it on Recovery Services Vault. At this moment the status is “Not configured”. In this demo, we will use “DT Cloud”

sr24

Click on DT Cloud | Click Configure Protection Settings

sr25

Select Target –> Microsoft Azure

sr26

Next step is configure replication location & frequency. Define

  • Storage location – where to put replicate data?
  • Encryption – To secure the data replicate and store in Azure, you can enable encryption.
  • Copy Frequency – 30 second, 5 minute, 15 minutes. You can define how frequent data should be synchronized between source and target location
  • Retain recovery point – 0 = only latest recovery point is stored on a replica host server.
  • Frequency of application consistency snapshot – define how often to create snapshot
  • Replication start time – Immediately or schedule based on time zone for 1st replication

Our example:-

Copy Frequency – 15 minutes
Recovery point – 24 hours
Frequency – 1 hours

How many recovery point is created?

Formula
60/copy_frequency during 1st hour + remaining hour

60/15 + 23

= 27 recovery point will be created

image

Once you click SAVE. It will start to

  • Configure Hyper-V Host for Azure
  • Pairing Cloud
  • Prepare the cloud protection configuration

Next step, cloud is ready. Let start to configure which VM to replicate to Azure.

VM Configuration

In Cloud, click Virtual Machine tab and select enable protection

sr31

  • Select VM to replicate and protect. Our example:- ICG-AP-DT01.

sr32

Then Azure Site Recovery Manager will initiate to perform

  • Enable Hyper-V Replica on the VM
  • Start Initial Replication VM to Azure (based on schedule or immediately)

Note:- This may take a while as huge virtual disk is been transfer to Azure. Go grab yourself a cup of coffee.

Final result should indicated as “Protected –OK”

sr40

Verification on VMM Server

  • On DT Cloud – Hyper-V Recover Manager Settings is Enabled and target location is Microsoft Azure
  • On VM – Protection is enabled and replication frequency is same as the setting configured on the Azure

sr35

sr36

Change VM Properties (In Azure)

  • Click on the VM, you can change the VM name, CPU and memory assign to the target VM

image

Network Mapping

Before failover, it is advisable to map the network between source and destination.

  • Go to Recovery Services Vault
  • Click on Resources tab
  • Select Source
  • Select Target
  • Select network
  • Click on MAP

sr38

  • We are mapping to our existing virtual network.

sr39

After you click save, any existing replica virtual machines that correspond to the source VM network will be connected to the target Azure networks. New virtual machines that are connected to the source VM network will be connected to the mapped Azure network after replication. If you modify an existing mapping with a new network, replica virtual machines will be connected using the new settings.

What do you learned from today post?

  • Create Cloud Configuration
  • Enable VM Protection
  • Map Source Network and Target Network

Let take a break and stay tuned for our next post- Microsoft Azure Site Recovery  : On-Premise to Microsoft Azure Part 3 (Click here) which talk about recovery plan and test failover.

Stay Tuned

Friday, June 27, 2014

Microsoft Azure Site Recovery : On-Premise to Microsoft Azure Part 1

 

Formerly known as Windows Azure Hyper-V Recovery Manager. Check out our last year post. Now it has rename to “Azure SIte Recovery ” with latest improvement. So

What can it do and why it is great? 

It provide orchestration and allowed us to replicate plus failover virtual machine on Hyper-V hosts between

a) on-premise to another on-premise

We have covered this section last year. Check out this post

b) on premise to Microsoft Azure

ASR1

Replication mechanism is using Hyper-V Replica that is built into Hyper-V in Windows Server 2012 or 2012 R2. By using Azure Site Recovery, we can perform service orchestration in term of replication, planned failover, unplanned failover and test failover. The entire engine is powered by Azure Site Recovery Manager.

Without investing a replication tool, we can now leverage on Hyper-V Replica to replicate a virtual machine to Azure. This is similar as Cold DR setup as suitable for those customer to has another set of workload running on Azure without heavily investing another data center.

We will cut our discussion short. If you would like to know more about Hyper-V Replica, please do check out below posts

Now you have understand how Hyper-V replica work and how the back end work to replica a virtual machine from one location to another. Let begin by looking on the requirement.

Requirements to configure Azure Site Recovery : on-premise to Azure

a) Hyper-V host running Windows Server 2012 or 2012 R2 (recommended) or Hyper-V Free Edition. Since it require Hyper-V Replica (built in features) , therefore you cannot use the Windows Server 2008 R2 Hyper-V. We encourage you to upgrade to at least Win 2012.

b) System Center Virtual Machine Manager 2012 SP1 (with latest CU) or R2 (recommended) – a must to create private cloud and configuration

c) Windows Azure subscription & use Azure Site Recovery Manager Preview features

Since the configuration is lengthy process, we will break this post into three segments:-

  • Pre-requisite setup Azure Site Recovery Manager
  • Configure Cloud Protection
  • Test Failover, Planned Failover and Unplanned Failover

Supported guest operating system:-

  • Windows 2008 or higher (must be 64 bits)
  • Centos, Opensuse, Suse, Ubuntu

Virtual disk requirements:-

  • OS- between 20MB – 127GB (1 disk only)
  • Data – between 20MB – 1023 GB (16 disks)

Note:-

  • Not supported for iSCSI Disk, Shared VHDX, FC Disk
  • Hard disk format :- VHD or VHDX (Generation 1 VM only)

Network adapter requirement:-

  • 1 network adapter

Generation VM supported

  • Generation 1 only

Here is the preparation that you need to prepare.

On Azure

1. Create a new vault

+New | Data Services | Recovery Services | Site Recovery Vault

sr1

sr2

2. Acquire certificate. On the VMM Server, you need to use Windows SDK 8.1 to create a certificate. Navigate to Windows Kit\8.1\bin\x64 and enter the following command to generate a certificate

sr4

Note:- Do take note that the certificate expire date should not be set more than 3 years.

  • Use mmc to export .pfx and .cer
  • Import the certificate to recovery service vault by clicking on Recovery Services | Manage Certificate

image

3. Get the vault key to use on VMM preparation

To get the key, click on MANAGE KEY and copy the key to use on our next step.

image

image

On VMM Server

Note:- Make sure, you have turn off VMM Services before install the provider

1. Download MS Azure Site Recovery Provider and install it on VMM Server.

  • Go to Azure and navigate to vault dashboard to get the provider

sr8

  • Install the provider

sr9

  • Configure the provider
    • Select the .pfx which you export out in previous step
    • Select the vault and paste the vault key

Sr12

To secure the data replicate to Azure, you can enable data encryption. Make sure you safe this certificate in a safe location. The certificate is require when you perform

  • Plan failover
  • Unplanned failover
  • Test failover

sr13

  • Make sure VMM Server Name is correct and tick to sync Private Cloud to Azure. This will allow entire Private Cloud configuration to sync into Azure.

Note:- Remember to create a private cloud and put assign VMs into Private Cloud. Only VM assigned to cloud will be able to replicate to Azure and manage by Azure Site Recovery Manager.

sr14

sr15

On Hyper-V Host Server

Download the MS Azure recovery Services agent and install it on Hyper-V host server

1. Download Azure Recovery Services Agent and install it on Hyper-V Server.

  • Go to Azure and navigate to vault dashboard to get the Hyper-V Host provider

Note:- Pre-requisite during provider installation. It will installed

  • Windows Identity Foundation
  • .Net Framework 4
  • Windows Powershell

sr16-pre-host

2. Define a sufficient cache location.

sr17-pre-host

We have completed and prepare our environment for Azure Site Recovery . Let take a break and stay tuned for our next post- Microsoft Azure Site Recovery : On-Premise to Microsoft Azure Part 2 (Click here)

Stay Tuned.

More details:-

Hyper-V Replica

Thursday, June 26, 2014

Free Toolkit–Microsoft Hyper-V, Veeam Backup, Starwind Virtual SAN and 5 Nine Manager

 

clip_image002[4]

Would you like to take advantage of the latest Microsoft Hyper-V version 2012 R2?
There is no better way to start virtualizing than with this FREE toolkit – an essential combination for every virtualization beginner:

  • Microsoft Hyper-V environment
  • Backup solution
  • Virtual storage
  • Hyper-V network management

With this free toolkit, you can create your own test lab, run a small business or even scale your production environment up to 1,000 VMs. It’s a FREE way to virtualize!

clip_image002

Friday, June 20, 2014

Backup SQL Database to Azure

With SQL Server 2014, you can now configure backup the database to Windows Azure as another alternative destination. Here is a simple step on how to configure the backup.

Product:-

  • SQL Server 2014 Standard Edition
  • Microsoft Azure

Scenario:-

SQL Server 2014 installed on a virtual machine and you would like to backup the database to Microsoft Azure Storage.

Steps:-

1. On Microsoft Azure, Create a new storage container

+ NEW –> Data Services –> Storage –> Quick Create

sal1

2. On SQL Server, Right click the database | Tasks | Backup

sal2

3. Select the destination “Backup to URL” and click Create

sal3

4. Select your Azure Publishing Settings and Storage Account. Make sure you get your subscription file by using Azure Powershell. (Get- AzurePublishSettingsFile)

Then click CREATE

sal4

5. Back to Azure, navigate to your storage that you’ve created earlier. Create a new container

sal4a

6. Set the container access to Private

sal4b

7. Back to SQL Server Management Studio, define the Azure Storage container that you’ve created in Step 6.

Click OK to start the backup

sal5

8. Backup job completed successfully

sal6

Finally verification on Microsoft Azure:-Bak file exist on Microsoft Azure

Verifyresult

That’s all for now . Easy right! Just give it a try on your environment. Good luck.

Monday, June 16, 2014

Configure VNet to VNet in Azure

 

In our previous post, we have explore on how to configure multi-site vpn in Azure for our domain controller. Next we are going look on how  to extend our data center network by connecting an Azure virtual network (Vnet) to another Azure virtual network. Both virtual network is going to connect to a secure tunnel using IpSec/IKE.

These connectivity is important when you would like to setup

  • Geo-redundancy via same region / different region without going over internet facing endpoint
  • Connect workload from different Azure subscription
  • Connect same region or different region
  • Setup a DR to another region. Example:- You have setup VM infrastructure at Southeast Asia Region – datacenter located in Singapore (SG). For redundancy we can setup geo-replication storage which replicate entire content to Hong Kong(HK) data center. But these implementation only contained content and we are still require to re-create cloud configuration and remap to our VM when disaster occur. Process of re-creating cloud configuration require more effort and downtime. Therefore one way to reduce downtime is setup another similar infrastructure in another region. That’s what this post is all about.

Let chec out our setup environment

  • Multi-site vpn connection between HQ and Branch. We had configured this our previous post. So we are going to skip these step.
  • Two different Azure subscription
    • Affinity Group 1- Southeast Asia (SG Datacenter)
    • Affinity Group 2 – East Asia (HK Datacenter)

VNet with Vnet

Region Local Network Virtual Network VPN Gateway
Southeast Asia Region 10.0.0.0/24 Ms4U-AzureVnet 138.91.33.133 [Created from our previous post]
East Asia Region 172.160.0.0/24 DR-Vnet [Will determine later]

Since we have completed our 1st region on our previous post, let move on to 2nd region.

  • Create Affinity Group

Settings –> Affinity Group –> +ADD –> “MS4U-DR (located in East Asia Region)

1

  • Create new storage

+NEW –> Data Services –> Storage –> Quick Create

2

  • Create new Virtual network

+New –> Network Services –> Virtual Network –> Custom Create

3

Define name “DR-Vnet”

4

Select “Configure site to site vpn”

5

Define 1st region virtual network address and temporary VPN Gateway IP

  • 10.0.0.0/24 (virtual network)
  • 1.1.1.1 (VPN gateway- we will modify later)

6

Define 2nd Region virtual network. Here we will be using 172.16.0.0/23 subnet. Make sure no overlap subnet on both virtual network.

7

  • Create VPN Gateway for 2nd virtual network – “DR-VNET”

Network –> DR-Vnet –> Dashboard –> Create Gateway –> Dynamic Routing

NOTE:- Creating vpn gateway will took around 20 minute.

8

  • While waiting, check the 1st virtual network VPN Gateway.Jot down the IP

9

  • Go to Networks –> Local Network –> Edit “Cross-MS4ULAN” VPN Gateway. Replace 1.1.1.1 with the correct VPN Gateway which we have capture from previous step

10

Now we have setup the 2nd virtual network. Let modify the 1st virtual network by export 1st virtual network configuration. To do so click on EXPORT.

Modify the entry to include 2nd virtual network (highlighted in green)

<NetworkConfiguration xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/ServiceHosting/2011/07/NetworkConfiguration">
  <VirtualNetworkConfiguration>
    <Dns>
      <DnsServers>
        <DnsServer name="MS4U-DC" IPAddress="192.168.20.10" />
      </DnsServers>
    </Dns>
    <LocalNetworkSites>
      <LocalNetworkSite name="MS4ULAN">
        <AddressSpace>
          <AddressPrefix>192.168.20.0/24</AddressPrefix>
        </AddressSpace>
        <VPNGatewayAddress>14.1.200.30</VPNGatewayAddress>
      </LocalNetworkSite>
      <LocalNetworkSite name="Site2MS4ULAN">
        <AddressSpace>
          <AddressPrefix>192.168.30.0/24</AddressPrefix>
        </AddressSpace>
        <VPNGatewayAddress>113.210.136.157</VPNGatewayAddress>
      </LocalNetworkSite>
     <LocalNetworkSite name="Cross-DR">
        <AddressSpace>
          <AddressPrefix>172.16.0.0/24</AddressPrefix>
        </AddressSpace>
        <VPNGatewayAddress>23.100.93.181</VPNGatewayAddress>
      </LocalNetworkSite>
    </LocalNetworkSites>
    <VirtualNetworkSites>
      <VirtualNetworkSite name="MS4U-AzureVnet" AffinityGroup="MS4U-LabAG">
        <AddressSpace>
          <AddressPrefix>10.0.0.0/24</AddressPrefix>
          <AddressPrefix>10.0.1.0/24</AddressPrefix>
          <AddressPrefix>10.0.2.0/24</AddressPrefix>
        </AddressSpace>
        <Subnets>
          <Subnet name="InfraSubnet">
            <AddressPrefix>10.0.0.0/27</AddressPrefix>
          </Subnet>
          <Subnet name="WebSubnet">
            <AddressPrefix>10.0.1.0/27</AddressPrefix>
          </Subnet>
          <Subnet name="DatabaseSubnet">
            <AddressPrefix>10.0.2.0/27</AddressPrefix>
          </Subnet>
          <Subnet name="GatewaySubnet">
            <AddressPrefix>10.0.2.32/29</AddressPrefix>
          </Subnet>
        </Subnets>
        <DnsServersRef>
          <DnsServerRef name="MS4U-DC" />
        </DnsServersRef>
        <Gateway>
          <ConnectionsToLocalNetwork>
            <LocalNetworkSiteRef name="MS4ULAN">
              <Connection type="IPsec" />
            </LocalNetworkSiteRef>
            <LocalNetworkSiteRef name="Site2MS4ULAN">
              <Connection type="IPsec" />
            </LocalNetworkSiteRef>
        <LocalNetworkSiteRef name="Cross-DR">
              <Connection type="IPsec" />
            </LocalNetworkSiteRef>
          </ConnectionsToLocalNetwork>
        </Gateway>
      </VirtualNetworkSite>
    </VirtualNetworkSites>
  </VirtualNetworkConfiguration>
</NetworkConfiguration>

Then import the new network configuration

+NEW –> Network Services –> Virtual Network –> Import Configuration

12

12a

13

Verify that new virtual network has added- “Cross-DR”

14

Before we connect both network, remember to change both shared key to the same key so these virtual network can communicate with each others.

On 1st virtual network

Set-AzureVnetGatewayKey –VnetName MS4U-AzureVnet –LocalNetworkSiteName Cross-DR –Sharedkey MS4UKEY

15

On 2nd virtual network

Set-AzureVnetGatewayKey –VnetName DR-Vnet -LocalNetworkSiteName Cross-MS4ULAN –Sharedkey MS4UKEY

16

17

Once you’ve change the key, click on CONNECT

18

Connection on 2nd virtual network is “Connected”

19

On the 1st virtual network is also “Connected”

21

Once connection has established, virtual machine from 1st region was able to ping to 2nd region. We have successfully connect vNet to another vNet.

Vnet

Our above configuration was guided from the documentation published by Microsoft Azure. To know more, please click here.