Migrate Alibaba ECS VM to Azure Cloud using Azure Site Recovery Services

In my previous blog, I have written how to migrate workloads from VMware to Azure Cloud.  In this tutorial, I am going to elaborate you how to migrate Amazon Web Services (AWS) EC2 virtual machines (VMs) to Azure VMs by using Azure Site Recovery.

Supported Workloads Which can be migrated:

  • Windows Server 2016 or later version
  • Red Hat Enterprise Linux 6.7

Prerequisites

  • The Mobility service must be installed on each VM that you want to replicate. Site Recovery installs this service automatically when you enable replication for the VM.
  • For non-domain joined Windows VMs, disable Remote User Access control on the local machine at the registry, under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System, add the DWORD entry LocalAccountTokenFilterPolicy and set the value to 1.
  • A separate VM in AWS subscriptions to use as Site Recovery Configuration Server. This instance must be running Windows Server 2012 R2.

Credential Requirements

  • root credential on the source Linux server
  • A Domain Admin Credentials for Windows VM.
  • A Local Admin Account for non-domain joined VM.

Prepare Azure resources (Target)

Step1: Create a Storage Account

  1. In the Azure portal, in the left menu, select Create a resource > Storage > Storage account.
  2. Create a Storage Account in your region.

Step2: Create a Recovery Vault

  1. In the Azure portal, select All services. Search for and then select Recovery Services vaults.
  2. Add new Recovery Vault in your region.

Step3: Add a separate network for migrated VM

  1. In the Azure portal, select Create a resource > Networking > Virtual network.
  2. Add new Network and Address Space.

Step4: Prepare Recovery Goal

  1. On your vault page in the Azure portal, in the Getting Started section, select Site Recovery, and then select Prepare Infrastructure.
  2. Create a protection goal from On-prem to Azure.
  3. When you’re done, select OK to move to the next section.

Step5: Create a Replication Policy

  1. To create a new replication policy, click Site Recovery infrastructure > Replication Policies > +Replication Policy. Create replication policy, specify a policy name.
  2. In RPO threshold, specify the recovery point objective (RPO) limit. This value specifies how often data recovery points are created. An alert is generated if continuous replication exceeds this limit.
  3. In Recovery point retention, specify how long (in hours) the retention window is for each recovery point. Replicated VMs can be recovered to any point in a window. Up to 24 hours retention is supported for machines replicated to premium storage, and 72 hours for standard storage.
  4. In App-consistent snapshot frequency, specify how often (in minutes) recovery points containing application-consistent snapshots will be created. Click OK to create the policy.

Prepare Source Environment (Alibaba Cloud)

Step6: Deploy an Alibaba ECS Instance (this is similar steps like OpenStack or AWS)

  1. Log on to the ECS console.
  2. In the left-side navigation pane, click Instances.
  3. On the Instances, list page, click Create Instance.
  4. Complete the Basic Configurations such as region, billing method, instance type, key pair, storage type and VPC to create an ECS instance.

Step7: Prepare Source ASR Configuration Server

  1. Log on to the Alibaba ECS instance (Step6) where you would like to install Configuration Server
  2. Configure the proxy on the EC2 instance VM you’re using as the configuration server so that it can access the service URLs.
  3. Download the Microsoft Azure Site Recovery Unified Setup. You can download it to your local machine and then copy it to the VM you’re using as the configuration server.
  4. Select the Download button to download the vault registration key. Copy the downloaded file to the VM you’re using as the configuration server.
  5. On the VM, right-click the installer you downloaded for Microsoft Azure Site Recovery Unified Setup, and then select Run as administrator.
  6. Under Before You Begin, select Install the configuration server and process server, and then select Next.
  7. In Third-Party Software License, select I accept the third-party license agreement and then select Next.
  8. In Registration, select Browse, and then go to where you put the vault registration key file. Select Next.
  9. In Internet Settings, select Connect to Azure Site Recovery without a proxy server, and then select Next.
  10. The Prerequisites Check page runs checks for several items. When it’s finished, select Next.
  11. In MySQL Configuration, provide the required passwords, and then select Next.
  12. In Environment Details, select No. You don’t need to protect VMware machines. Then, select Next.
  13. In Install Location, select Next to accept the default.
  14. In Network Selection, select Next to accept the default.
  15. In Summary, select Install. Installation Progress shows you information about the installation process. When it’s finished, select Finish. A window displays a message about a reboot. Select OK. Next, a window displays a message about the configuration server connection passphrase. Copy the passphrase to your clipboard and save it somewhere safe.
  16. On the VM, run cspsconfigtool.exe to create one or more management accounts on the configuration server. Make sure that the management accounts have administrator permissions on the EC2 instances that you want to migrate.

Step8: Enable Replication for an Alibaba ECS VM

  1. Click Replicate application > Source.
  2. In Source, select the configuration server.
  3. In Machine type, select Physical machines.
  4. Select the process server (the configuration server). Then click OK.
  5. In Target, select the subscription and the resource group in which you want to create the Azure VMs after failover. Choose the deployment model that you want to use in Azure (classic or resource management).
  6. Select the Azure storage account you want to use for replicating data.
  7. Select the Azure network and subnet to which Azure VMs will connect when they’re created after failover.
  8. Select Configure now for selected machines, to apply the network setting to all machines you select for protection. Select Configure later to select the Azure network per machine.
  9. In Physical Machines, and click +Physical machine. Specify the name and IP address. Select the operating system of the machine you want to replicate. It takes a few minutes for the servers to be discovered and listed.
  10. In Properties > Configure properties, select the account that will be used by the process server to install the Mobility service on the machine automatically.
  11. In Replication settings,> Configure replication settings, verify that the correct replication policy is selected.
  12. Click Enable Replication. You can track the progress of the Enable Protection job in Settings > Jobs > Site Recovery Jobs. After the Finalize Protection job runs the machine is ready for failover.

Test failover at Azure Portal

Step9: Test a Failover

  1. On the page for your vault, go to Protected items > Replicated Items. Select the VM, and then select Test Failover.
  2. Select a recovery point to use for the failover:
  3. Latest processed: Fails over the VM to the latest recovery point that was prepared by Site Recovery. The time stamp is shown. With this option, no time is spent preparing data, so it provides a low recovery time objective (RTO).
  4. Latest app-consistent: This option fails over all VMs to the latest app-consistent recovery point. The time stamp is shown.
  5. Custom: Select any recovery point.
  6. In Test Failover, select the target Azure network to which Azure VMs will be connected after failover occurs. This should be the network you created in Prepare Azure resources.
  7. Select OK to begin the failover. To track progress, select the VM to view its properties. Or you can select the Test Failover job on the page for your vault. To do this, select Monitoring and reports > Jobs > Site Recovery jobs.
  8. When the failover finishes, the replica Azure VM appears in the Azure portal. To view the VM, select Virtual Machines. Ensure that the VM is the appropriate size, that it’s connected to the right network, and that it’s running.
  9. You should now be able to connect to the replicated VM in Azure.
  10. To delete Azure VMs that were created during the test failover, select Cleanup test failover in the recovery plan. In Notes, record and save any observations associated with the test failover.

Migrate an Alibaba ECS Instance to Azure Cloud

Step10: Trigger Azure Migration

  1. In Protected items > Replicated items, select the AWS instances, and then select Failover.
  2. In Failover, select a Recovery Point to failover to. Select the latest recovery point.
  3. Select Shut down the machine before beginning failover if you want Site Recovery to attempt to do a shutdown of source virtual machines before triggering the failover. Failover continues even if shutdown fails. You can follow the failover progress on the Jobs
  4. Ensure that the VM appears in Replicated items.
  5. Right-click each VM, and then select Complete Migration. This finishes the migration process, stops replication for the AWS VM, and stops Site Recovery billing for the VM.

Migrate SQL Server to Azure SQL Database using Database Migration Services (DMS)

The Data Migration Assistant (DMA) helps you upgrade to a modern data platform by detecting compatibility issues that can impact database functionality in your new version of SQL Server or Azure SQL Database. The Data Migration Service (DMA) lets you migrate on-premises SQL Server or SQL Database hosted in AWS or GCP migrate to Azure SQL Database. There are three simple steps require to migrate Database to Azure SQL. There are two migration approach you can take, Offline and Online migration.

  1. Assess on-premises SQL Server instance(s) migrating to Azure SQL database(s).
  2. Discover issues that can affect an upgrade to an on-premises SQL Server.
  3. Migrate an on-premises SQL Server instance to Azure SQL Server
Azure SQL Database Migration Steps

Prerequisites:

  • SQL Server sysadmin role
  • distributor role for source SQL Server
  • SQL Server Management Studio (SSMS)
  • Co-Administrator or Contributor role in Azure cloud
  • Source Database is SQL Server 2005 or later version
  • Target database is Azure SQL Database and Azure SQL Database Managed Instance
  • Azure Virtual Network (VNET) for the Azure Database Migration Service by using the Azure Resource Manager deployment model.
  • Ensure that your VNET Network Security Group rules don’t block the following communication ports 443, 53, 9354, 445, 12000.
  • Download and install the Data Migration Assistant v3.3 or later.

Prepare Target Database:

A single database has a defined set of compute, memory, IO, and storage resources using one of two purchasing models.

  1. Log on to Azure Portal
  2. Select Create a resource in the upper left-hand corner of the Azure portal.
  3. Select Databases and then select SQL Database.
  4. In the Create SQL Database form, type or select Database name, Subscription, Resource group, Select source>select OK.
  5. Under Server, select Create new.
  6. In the New server form, create Server name, location, admin Name and password
  7. Choose Select.
  8. On the SQL Database form, select Pricing tier. Explore the amount of DTUs and storage available for each service tier.
  9. For this quickstart, select the Standard service tier, and then use the slider to select DTUs (S0) and GB of storage.
  10. Select Apply.
  11. On the SQL Database form, select Create to deploy and provision the resource group, server, and database.
  12. Deployment takes a few minutes. You can select Notifications on the toolbar to monitor deployment progress.
  13. On the SQL Database page for your database, select Query editor (preview) in the left menu.
  14. Enter your login information, and select OK.
  15. Enter the following query in the Query editor pane. Select Run, and then review the query results in the Results pane.

SELECT TOP 20 pc.Name as CategoryName, p.name as ProductName

FROM SalesLT.ProductCategory pc

JOIN SalesLT.Product p

ON pc.productcategoryid = p.productcategoryid;

Assess your on-premises database:

  1. In the Data Migration Assistant, select the New (+) icon, and then select the Assessment project type.
  2. Specify a project name, in the Source server type text box, select SQL Server, in the Target server type text box, select Azure SQL Database, and then select Create to create the project.
  3. When you’re assessing the source SQL Server database migrating to a single database or pooled database in Azure SQL Database, you can choose one or both of the following assessment report types: Check database compatibility, Check feature parity, Both report types are selected by default.
  4. In the Data Migration Assistant, on the Options screen, select Next.
  5. On the Select sources screen, in the Connect to a server dialog box, provide the connection details to your SQL Server, and then select Connect.
  6. In the Add sources dialog box, select AdventureWorks2012, select Add, and then select Start Assessment.

Create a Database Migration Services instance:

  1. In the Azure portal, select + Create a resource, search for Azure Database Migration Service, and then select Azure Database Migration Service from the drop-down list.
  2. On the Azure Database Migration Service screen, select Create.
  3. On the Create Migration Service screen, specify a name for the service, the subscription, and a new or existing resource group.
  4. Select the location in which you want to create the instance of the Azure Database Migration Service.
  5. Select an existing virtual network (VNET) or create a new one.
  6. Select a pricing tier.
  7. Select Create to create the service.

Create a migration project:

  1. In the Azure portal, select All services, search for Azure Database Migration Service, and then select Azure Database Migration Services.
  2. On the Azure Database Migration Services screen, search for the name of the Azure Database Migration Service instance that you created, and then select the instance.
  3. Select + New Migration Project.
  4. On the New migration project screen, specify a name for the project, in the Source server type text box, select SQL Server, in the Target server type text box, select Azure SQL Database, and then for Choose type of activity, select Offline data migration or Online data migration.
  5. Select Create and run activity to create the project and run the migration activity

Specify Source On-premises SQL Database:

  1. On the Migration source detail screen, specify the connection details for the source SQL Server instance e.g. FQDN of SQL Server, admin name (domain name\username) and password.
  2. Click Encrypt Connection. Click Save.

Specify Target Azure SQL Database:

DMS Wizard
  1. On the Migration target details screen, specify the connection details for the target Azure SQL Database Server.
  2. Select Save, and then on the Map to target databases screen, map the source and the target database for migration.
  3. Select Save, on the Select tables screen, expand the table listing, and then review the list of affected fields.
  4. Select Save, on the Migration summary screen, in the Activity name text box, specify a name for the migration activity.
  5. Expand the Validation option section to display the Choose validation option screen, and then specify whether to validate the migrated databases for Schema comparison, Data consistency, and Query correctness.
  6. Select Save, review the summary to ensure that the source and target details match what you previously specified.
  7. Select Run migration.
  8. After the migration completes, select Download report to get a report listing the details associated with the migration process.
  9. Verify the target database(s) on the target Azure SQL Database server.

Monitor & Cutover to Azure SQL Database:

Data migration using SQL Management Studio
  1. On the migration activity screen, select Refresh to update the display until the Status of the migration shows as Running.
  2. Click on a specific database to get to the migration status for Full data load and Incremental data sync operations.
  3. When you’re ready to complete the database migration, select Start Cutover.
  4. Make sure to stop all the incoming transactions to the source database; wait until the Pending changes counter shows 0.
  5. Select Confirm, and the select Apply.
  6. When the database migration status shows Completed, connect your applications to the new target Azure SQL Database.

Azure Stack Pricing Model

Azure Stack is sold as an integrated system, with software pre-installed on validated hardware. Azure Stack comes with two operational modes—Connected and Disconnected. Connected Mode use Azure metering services with the Microsoft Azure Cloud. The Disconnected Mode does not use Azure metering services. The Disconnected Mode is based on capacity pricing model. The Connected Mode is a Pay-as-you-use software pricing model.

Azure Stack.png

Licensing Model

Payment Method Description License Type
PAYG No upfront cost EA or CSP
Capacity Model Fixed Fees per annum EA Only

Windows and SQL License

You have to use licenses from any channel (EA, SPLA, Open, and others), as long as you comply with all software licensing and product terms.

Linux Licenses

You have to use RedHat or other Linux licenses on the Azure Stack if you choose to use Linux Operating Systems. You have to pay to the software vendor for use of their software on the Azure Stack.

Connected Mode for Cloud Service Provider (CSP)

Azure Stack offers pay-as-you-use pricing, just like you get with Azure. Run infrastructure as a service (IaaS) and platform as a service (PaaS) on Azure Stack with no upfront fees, and use the same subscriptions, monetary commitments, and billing tools as Azure. The pay-as-you-use package is available through Enterprise Agreements (EA) and the Cloud Solution Provider program (CSP).

Service Type Description Hourly Rate Monthly Rate
Compute Base VM $0.011/vCPU $8 vCPU
  Windows VM $0.059/vCPU $43 vCPU
Storage Storage   $0.008/GB
  Table & Queue   $0.023/GB
  Unmanaged Disk   $0.015/GB
App Services Web Apps, API, Functions $0.072/vCPU

 

$53 vCPU

The Connected Mode is available through both Enterprise Agreement (EA) and Cloud Service Provider (CSP) partner channel. Azure MSDN, Free Trial, and Biz Spark subscription IDs cannot be used in conjunction with Azure Stack.

Your Azure Stack usage will be metered and integrated into one bill with your Azure usage.

Use cases:

The customer already has Azure Subscription. The customer wants to establish hybrid cloud in conjunction with Azure Cloud.

Disconnected Mode for Azure Stack On-premises

the App Service package, which includes App Service, base virtual machines, and Azure Storage ($400/core/year), and the IaaS package, which includes base virtual machines and Azure Storage ($144/ core/year.) With the capacity model, you use your existing on-premises licenses to deploy Windows Server and SQL Server virtual machines.

The capacity model is available via EA only. It is purchased as an Azure Plan SKU via normal volume licensing channels.

Use Cases

The customer wants to build their own private cloud platform and offer services to their departments and subsidiaries. The purpose of this exercise is to segregate billing of each department but maintain single ICT organisation.

Azure Stack Support

Azure Stack support is a consistent, integrated, hybrid support experience that covers the full system lifecycle. If you already have Premier, Azure, or Partner support with Microsoft, your Azure Stack software support is included. You need only make one call to the vendor of your choice (Microsoft or hardware partner) for any Azure Stack issue.

For up-to-date pricing visit Microsoft website.

Azure Site-to-Site IPSec VPN connection with Citrix NetScaler (CloudBridge)

An Azure Site-to-Site VPN gateway connection is used to connect on-premises network to an Azure virtual network over an IPsec/IKE (IKEv1 or IKEv2) VPN tunnel. This type of connection requires a VPN device located on-premises that has an externally facing public IP address assigned to it.

In this example, I am going to use Citrix CloudBridge feature of a NetScaler. The Citrix CloudBridge works in a pair, one at each end of a link, to accelerate traffic over the link. The transformations done by the sender are reversed by the receiver. One CB virtual appliance  can handle many links, so you do not have to dedicate a pair to each connection. You need just one CB virtual appliance per site to handle traffic to and from Azure datacenter to on-premises datacenter. In a Citrix CloudBridge Connector tunnel, IPSec ensures:

  • Data integrity
  • Data origin authentication
  • Data confidentiality (encryption)
  • Protection against replay attacks

The below exercise creates a IPSec tunnel between 66.128.x.x (On-prem) to 168.63.x.x (Azure).

Basic Requirements:

  • Make sure that the public IPv4 address for your VPN device is not located behind a NAT firewall
  • Make sure you have correct NSG rules are configured for you to access on-premises VM from Azure VM or vise-versa.

IP Address Requirements:

IP address of the CloudBridge Connector tunnel end point (CB Appliance) in the on-premises side 66.128.x.x
IP address of the CloudBridge Connector tunnel end point in the Azure VPN Gateway 168.63.x.x
Datacenter Subnet, the traffic of which is to traverse the CloudBridge Connector tunnel 10.120.0.0/23
Azure Subnet, the traffic of which is to traverse the CloudBridge Connector tunnel 10.10.0.0/22

Citrix NetScaler Settings

IPSec profile CB_Azure_IPSec_Profile IKE version = v1

Encryption algorithm = AES

Hash algorithm = HMAC SHA1

CloudBridge Connector tunnel CB_Azure_Tunnel Remote IP = 168.63.x.x

Local IP= 66.128.x.x (SNIP)

Tunnel protocol = IPSec

IPSec profile= CB_Azure_IPSec_Profile

Policy based route CB_Azure_Pbr Source IP range = Subnet in the datacenter =10.120.0.0-10.120.1.254

Destination IP range =Subnet in Azure =10.10.0.1 – 10.10.3.254

IP Tunnel = CB_Azure_Tunnel

Azure VPN Gateway Settings

Public IP Address of the Azure VPN Gateway 168.63.x.x
Local Network On-prem Network VPN Device IP address = 66.128.x.x (SNIP)

On-prem Subnet =10.120.0.0/24

Virtual Network CloudBridge Tunnel in Azure Side Address Space of the Azure vNET= 10.10.0.0/22

Trusted Subnet within the vNET = 10.10.0.1/24

Untrusted Subnet within the vNET = 10.10.1.1/24

Gateway Subnet=10.10.2.0/24

Region Australia East
VPN Type Route-based
Connection Type Site-to-site (IPsec)
Gateway Type VPN
Shared key Sample Shared Key DkiMgMdcbqvYREEuIvxsbKkW0FOyDiLM

Configuration of Citrix NetScaler CloudBridge Feature

Step1: Create IPSec Profile

add ipsec profile CB_Azure_IPSec_Profile –psk  DkiMgMdcbqvYREEuIvxsbKkW0FOyDiLM  -ikeVersion v1 –lifetime 31536000

Note: DkiMgMdcbqvYREEuIvxsbKkW0FOyDiLM is also used in the Azure VPN connection.

Step2: Create IPSec Tunnel

add iptunnel CB_Azure_Tunnel 168.63.x.x 255.255.255.255 66.128.x.x –protocol IPSEC –ipsecProfileName CB_Azure_IPSec_Profile

Step3: Create PBR Rule

add pbr CB_Azure_Pbr -srcIP 10.120.0.0-10.120.1.255 –destIP 10.10.0.0-10.10.3.255 –ipTunnelCB_Azure_Tunnel

Step4: Apply Settings

apply pbrs

You can configure NetScaler using GUI as well. here is an example.

  1. Access the configuration utility by using a web browser to connect to the IP address of the NetScaler appliance in the datacenter.
  2. Navigate to System > CloudBridge Connector.
  3. In the right pane, under Getting Started, click Create/Monitor CloudBridge.
  4. Click Get Started> In the CloudBridge Setup pane, click Microsoft Windows Azure.
  5. In the Azure Settings pane, in the Gateway IP Address* field, type the IP address of the Azure gateway. The CloudBridge Connector tunnel is then set up between the NetScaler appliance and the gateway. In the Subnet (IP Range)* text boxes, specify a subnet range (in Azure cloud), the traffic of which is to traverse the CloudBridge Connector tunnel. Click Continue.
  6. In the NetScaler Settings pane, from the Local Subnet IP* drop-down list, select a publicly accessible SNIP address configured on the NetScaler appliance. In Subnet (IP Range)* text boxes, specify a local subnet range, the traffic of which is to traverse the CloudBridge Connector tunnel. Click Continue.
  7. In the CloudBridge Setting pane, in the CloudBridge Name text box, type a name for the CloudBridge that you want to create.
  8. From the Encryption Algorithm and Hash Algorithm drop-down lists, select the AES and HMAC_SHA1 algorithms, respectively. In the Pre Shared Security Key text box, type the security key.
  9. Click Done.

Configuration of an IPSec Site-to-Site VPN in the Azure Subscription 

Step1: Connect to Azure Subscription

Login-AzureRmAccount

Get-AzureRmSubscription

Select-AzureRmSubscription -SubscriptionName “99ebd-649c-466a-a670-f1a611841”

Step2: Create Azure Resource Group in your region

New-AzureRmResourceGroup -Name TestRG1 -Location “Australia East”

Step3: Create vNET and Subnets

$subnet1 = New-AzureRmVirtualNetworkSubnetConfig -Name “Tursted” -AddressPrefix 10.10.0.0/24

$subnet2 = New-AzureRmVirtualNetworkSubnetConfig -Name “UnTursted” -AddressPrefix 10.10.1.0/24

$subnet3 = New-AzureRmVirtualNetworkSubnetConfig -Name “GatewaySubnet” -AddressPrefix 10.10.2.0/24

$vnet=New-AzureRmVirtualNetwork -Name TestVNet1 -ResourceGroupName TestRG1 -Location “Australia East” -AddressPrefix 10.10.0.0/22 -Subnet $subnet1, $subnet2, $subnet3

Set-AzureRmVirtualNetwork -VirtualNetwork $vnet

Step4: Create On-premises Network

New-AzureRmLocalNetworkGateway -Name Site2 -ResourceGroupName TestRG1 -Location “Australia East” -GatewayIpAddress “66.128.x.x” -AddressPrefix “10.120.0.0/24”

New-AzureRmLocalNetworkGateway -Name Site2 -ResourceGroupName TestRG1 -Location “East US” -GatewayIpAddress “23.99.221.164” -AddressPrefix @(“10.120.0.0/24”,”10.120.1.0/24”)

Step5: Request a Public IP Address

$gwpip= New-AzureRmPublicIpAddress -Name gwpip -ResourceGroupName TestRG1 -Location “Australia East” -AllocationMethod Dynamic

Step6: Create Gateway IP Address

$vnet = Get-AzureRmVirtualNetwork -Name TestVNet1 -ResourceGroupName TestRG1

$subnet = Get-AzureRmVirtualNetworkSubnetConfig -Name “GatewaySubnet” -VirtualNetwork $vnet

$gwipconfig = New-AzureRmVirtualNetworkGatewayIpConfig -Name gwipconfig1 -SubnetId $subnet.Id -PublicIpAddressId $gwpip.Id

Step7: Create VPN Gateway

New-AzureRmVirtualNetworkGateway -Name VNet1GW -ResourceGroupName TestRG1 -Location “Australia East” -IpConfigurations $gwipconfig -GatewayType Vpn -VpnType RouteBased -GatewaySku VpnGw1

Step8: Extract public IP address of the VPN Gateway

Get-AzureRmPublicIpAddress -Name GW1PublicIP -ResourceGroupName TestRG1

Step9: Create VPN Connection

$gateway1 = Get-AzureRmVirtualNetworkGateway -Name VNet1GW -ResourceGroupName TestRG1

$local = Get-AzureRmLocalNetworkGateway -Name Site2 -ResourceGroupName TestRG1

New-AzureRmVirtualNetworkGatewayConnection -Name VNet1toSite2 -ResourceGroupName TestRG1 -Location “East US” -VirtualNetworkGateway1 $gateway1 -LocalNetworkGateway2 $local -ConnectionType IPsec -RoutingWeight 10 -SharedKey “ DkiMgMdcbqvYREEuIvxsbKkW0FOyDiLM”

Step10: verify Connection

Get-AzureRmVirtualNetworkGatewayConnection -Name MyGWConnection -ResourceGroupName MyRG

Configuring Azure ExpressRoute using PowerShell

Microsoft Azure ExpressRoute is a private connection from on-premises networks to the Microsoft cloud over a private peering facilitated by a network service provider. With ExpressRoute, you can establish a faster, low latencies and reliable connection to Microsoft cloud services, such as Microsoft Azure, Office 365, and Dynamics 365. ExpressRoute is available to all continent and in all geopolitical boundaries.

ExpressRoute Circuit Connectivity Model

  • Co-located at a cloud exchange- The on-premises infrastructure is co-located in a facility with Microsoft Azure Cloud, you can order virtual cross-connections to the Microsoft cloud through the co-location provider’s Ethernet exchange. Data center providers can offer either Layer 2 cross-connections, or managed Layer 3 cross-connections between your infrastructure in the colocation facility and the Microsoft cloud.
  • Point-to-point Ethernet connections- You can connect your on-premises infrastructure to the Microsoft cloud through point-to-point Ethernet links. Point-to-point Ethernet providers can offer Layer 2 connections, or managed Layer 3 connections between your site and the Microsoft cloud.
  • Any-to-any (IPVPN) networks- You can integrate company WAN with the Microsoft cloud. IPVPN providers are typically MPLS connection between your branch offices and data centers. The Microsoft cloud can be interconnected to company WAN to make it look just like another branch office.

Key Features:

  • Layer 3 connectivity between your on-premises network and the Microsoft Cloud through a connectivity provider.
  • Connectivity to Microsoft cloud services across all regions in the geopolitical region.
  • Global connectivity to Microsoft services across all regions with an ExpressRoute premium add-on.
  • Dynamic routing between your network and Microsoft over industry standard protocols (BGP).
  • Built-in redundancy in every peering location for higher reliability.
  • QoS support for Skype for Business.
  • Bandwidth starting from 50Mbps to 10Gbps

Subscription requirements:

  • A valid and active Microsoft Azure account or an active Office 365 subscription. This account is required to set up the ExpressRoute circuit. ExpressRoute circuits are resources within Azure subscriptions.

Partners Requirements:

Network requirements:

  • Redundant connectivity-Microsoft requires redundant BGP sessions to be set up between Microsoft’s routers and the peering routers, even when you have just one physical connection to a cloud exchange.
  • Routing-ExpressRoute provider needs to set up and manage the BGP sessions for routing domains. Some Ethernet connectivity provider or cloud exchange provider may offer BGP management as a value-add service.
  • NAT-Microsoft only accepts public IP addresses through Microsoft peering. If you are using private IP addresses in your on-premises network, you or your provider need to translate the private IP addresses to the public IP addresses using the NAT.
  • QoS-Skype for Business has various services (for example; voice, video, text) that require differentiated QoS treatment. You and your provider should follow the QoS requirements.
  • Network Security- consider network security when connecting to the Microsoft Cloud via ExpressRoute.

ExpressRoute Peering

  • Private peering- The private peering domain is considered to be a trusted extension of on-premises core network into Microsoft Azure. You can set up bi-directional connectivity between your core network and Azure virtual networks.
  • Public peering- In a simple terminology, the public peering is a network peering between public domain to on-premises DMZ and connect to all Azure services on their public IP addresses from company WAN without having to connect to the internet.
  • Microsoft peering- ExpressRoute provides private network connectivity to Microsoft cloud services. Infrastructure and platform services running in Azure often benefit by addressing network architecture and performance considerations. Therefore, we recommend enterprises use ExpressRoute for Azure.
  • Microsoft peering is used specifically for SaaS like Office 365 and Dynamics 365, were created to be accessed securely and reliably via the Internet. Therefore, we only recommend ExpressRoute for these applications in specific scenarios.

 Provisioning an ExpressRoute

Step1: Login and Select the subscription

Login-AzureRmAccount

Get-AzureRmSubscription

Copy the name of the subscription to be used for next command.

Select-AzureRmSubscription -SubscriptionId “Company Default”

Step2: Copy the name of the ExpressRoute Provider information to be used for next command.

Name, PeeringLocations, BandwidthsOffered, Sku

Get-AzureRmExpressRouteServiceProvider

Step3: Create new ExpressRoute

New-AzureRmExpressRouteCircuit -Name “On-premtoAzureCloud” -ResourceGroupName “ExpressRouteRG” -Location “Australia East” -SkuTier Standard -SkuFamily MeteredData -ServiceProviderName “Equinix” -PeeringLocation “Sydney” -BandwidthInMbps 200

Once you have created new ExpressRoute, you will see the below status of ExpressRoute.

NotProvisioned & Enabled, Provisioning & Enabled, Provisioned & Enabled

Step4: Record Subscription ID, service Key, Location and send this information to your ExpressRoute circuit provider to provision and activate services.

get-help New-AzureRmExpressRouteCircuit –detailed

Step5: List of All ExpressRoute and record the information for next command

Get-AzureRmExpressRouteCircuit -Name “ExpressRouteARMCircuit” -ResourceGroupName “ExpressRouteResourceGroup”

Step5: Connect a virtual network in the same subscription to a circuit

$circuit = Get-AzureRmExpressRouteCircuit -Name “MyCircuit” -ResourceGroupName “MyRG”

$gw = Get-AzureRmVirtualNetworkGateway -Name “ExpressRouteGw” -ResourceGroupName “MyRG”

$connection = New-AzureRmVirtualNetworkGatewayConnection -Name “ERConnection” -ResourceGroupName “MyRG” -Location “East US” -VirtualNetworkGateway1 $gw -PeerId $circuit.Id -ConnectionType ExpressRoute

Step6: Create Azure private peering for Azure Services

Make sure that you have the following items before you proceed with the next steps:

  • A /30 subnet for the primary and secondary link. This must not be part of any address space reserved for virtual networks.
  • A valid VLAN ID to establish this peering on. Ensure that no other peering in the circuit uses the same VLAN ID.
  • AS number for peering. You can use both 2-byte and 4-byte AS numbers. You can use a private AS number for this peering. Ensure that you are not using 65515.

$ckt = Get-AzureRmExpressRouteCircuit -Name “ExpressRouteARMCircuit” -ResourceGroupName “ExpressRouteResourceGroup”

Add-AzureRmExpressRouteCircuitPeeringConfig -Name “AzurePrivatePeering” -ExpressRouteCircuit $ckt -PeeringType AzurePrivatePeering -PeerASN 100 -PrimaryPeerAddressPrefix “10.0.0.0/30” -SecondaryPeerAddressPrefix “10.0.0.4/30” -VlanId 200

Set-AzureRmExpressRouteCircuit -ExpressRouteCircuit $ckt

Get-AzureRmExpressRouteCircuitPeeringConfig -Name “AzurePrivatePeering” -Circuit $ckt

Step7: Configure Azure public peering for the circuit if you require a public peering refer to the explanation section.

  • Make sure that you have the following information before you proceed further:
  • A /30 subnet for the primary and secondary link. This must be a valid public IPv4 prefix.
  • A valid VLAN ID to establish this peering on. Ensure that no other peering in the circuit uses the same VLAN ID.
  • AS number for peering. You can use both 2-byte and 4-byte AS numbers.

Add-AzureRmExpressRouteCircuitPeeringConfig -Name “AzurePublicPeering” -ExpressRouteCircuit $ckt -PeeringType AzurePublicPeering -PeerASN 100 -PrimaryPeerAddressPrefix “12.0.0.0/30” -SecondaryPeerAddressPrefix “12.0.0.4/30” -VlanId 100

Set-AzureRmExpressRouteCircuit -ExpressRouteCircuit $ckt

Step8: Configure Microsoft peering for the circuit if you require a public peering refer to the explanation section.

  • Make sure that you have the following information before you proceed:
  • A /30 subnet for the primary and secondaary link. This must be a valid public IPv4 prefix owned by you and registered in an RIR / IRR.
  • A valid VLAN ID to establish this peering on. Ensure that no other peering in the circuit uses the same VLAN ID.
  • AS number for peering. You can use both 2-byte and 4-byte AS numbers.
  • Advertised prefixes: You must provide a list of all prefixes you plan to advertise over the BGP session. Only public IP address prefixes are accepted. You can send a comma separated list if you plan to send a set of prefixes. These prefixes must be registered to you in an RIR / IRR.
  • Customer ASN: If you are advertising prefixes that are not registered to the peering AS number, you can specify the AS number to which they are registered. This is optional.
  • Routing Registry Name: You can specify the RIR / IRR against which the AS number and prefixes are registered.

Add-AzureRmExpressRouteCircuitPeeringConfig -Name “MicrosoftPeering” -ExpressRouteCircuit $ckt -PeeringType MicrosoftPeering -PeerASN 100 -PrimaryPeerAddressPrefix “123.0.0.0/30” -SecondaryPeerAddressPrefix “123.0.0.4/30” -VlanId 300 -MicrosoftConfigAdvertisedPublicPrefixes “123.1.0.0/24” -MicrosoftConfigCustomerAsn 23 -MicrosoftConfigRoutingRegistryName “ARIN”

Set-AzureRmExpressRouteCircuit -ExpressRouteCircuit $ckt

To Upgrade the SKU from metered to unlimited. Implement the below command to upgrade ExpressRoute SKU

$ckt = Get-AzureRmExpressRouteCircuit -Name “ExpressRouteARMCircuit” -ResourceGroupName “ExpressRouteResourceGroup”

$ckt.Sku.Family = “UnlimitedData”

$ckt.sku.Name = “Premium_UnlimitedData”

Set-AzureRmExpressRouteCircuit -ExpressRouteCircuit $ckt

Migrate On-premises Exchange Server to Office 365 using MigrationWiz

Assumptions:

  • An operational on-premises Microsoft messaging environment or an IMAP Source
  • An operational Microsoft Office 365 tenant for Exchange Online
  • Active Directory synchronised with Microsoft Azure Active Directory using DirSync
  • Licenses are assigned to Active Users.
  • There are place holder mailboxes e.g. user@tenant.onmicrosoft.com or real mailboxes e.g. user@domain.com as destination mailboxes.

Credit: BitTitan knowledge Base Articles. KBs mentioned here are BitTitan KBs not Microsoft KB.

Prepare Source: Exchange Environment

  1. Set up an administrator account “Domain\MigrationWiz” for migration on the Source Exchange mailbox server. Grant Domain Admins and Organisation Management Role for this Admin Account. KB004944
  2. Test OWA using https://mail.domain.com/owa. KB004392
  3. Test mailbox access. KB004616
  4. Disable the Exchange throttling policy during migration. KB004945
  5. Allow impersonation by MigrationWiz account

New-ManagementRoleAssignment –Name:impersonationAssignmentName –Role:ApplicationImpersonation –User:MigrationWiz

  1. Grant Full Access to MigrationWiz Admin Account for all mailboxes

Get-Mailbox -Resultsize Unlimited | Add-MailboxPermission -User MigrationWiz -AccessRights FullAccess -InheritanceType All

  1. Enable Circular Logging on the Mailbox Database properties. De-mount Mailbox Database and remount mailbox database after running the below command.

Get-MailboxDatabase | Set-MailboxDatabase -CircularLoggingEnabled $true

  1. Grant higher CPU and Memory to the source Server.
  2. Allocate minimum 50MB/s to 100MB/s bandwidth to outgoing network from on-premises Exchange Environment to internet
  3. Allow outbound Office 365 Ports and URLs on the firewall devices

Prepare the Destination: Exchange Online Environment

  1. Create an administrator account “MigrationWiz@tenant.onmicrosoft.com” in Office 365 to be used for migration, or use the global admin account for the tenant. KB004948
  2. If Microsoft DirSync was used to create and synchronize the local AD accounts up to Office 365, remember to disable it prior to using MigrationWiz. KB004336

Note: BitTitan recommend stopping DirSync during migration however I have migrated mailboxes without stopping DirSync. You must not change mail attribute and UPNs of any Active Directory Account during migration phase. You can do it later using PowerShell Cmdlets in bulk.

  1. Set up accounts on Office 365 and assign licenses. These can be created in several ways:
    • By bulk import using PowerShell via CSV file input.
    • By Microsoft DirSync. Read this very important Knowledge Base article before running Microsoft DirSync, to see if it should be run prior to migration. KB004336
    • By BitTitan Sync tool. KB004336
  2. Prepare tenant to send and receive large mail items. KB005139
  3. Contact Microsoft to ask to have the tenant EWS throttling limits raised for 60 days. Note: This step is only required if your Source environment will support migration speeds that are faster than the Destination. KB005493
  4. Allow impersonation by MigrationWiz Account

New-ManagementRoleAssignment –Name:impersonationAssignmentName –Role:ApplicationImpersonation –User:MigrationWiz@tenant.onmicrosoft.com

  1. Grant Full Access Permission to MigrationWiz Account

Create a CSV file with these CSV Headers

name, user

mailbox1@domain.com, MigrationWiz@tenant.onmicrosoft.com

mailbox2@domain.com, MigrationWiz@tenant.onmicrosoft.com

$Mailboxes = import-csv C:\CSV\FullAccess.csv

Foreach ($Mailbox in $Mailboxes)

{Add-MailboxPermission -Identity $Mailbox.Name -user $Mailbox.User -AccessRights ‘FullAccess’ -InheritanceType All}

 Migrating On-premises Mailbox to Office 365 using MigrationWiz

Buy Licenses

Note: This step can be completed by a re-seller. You must provide company email address (migrationadmin@company.com ) to associate your company with MigrationWiz Portal. This Email Address is the log on details of Migration Admin who will perform the migration task.

  1. Create the customer. KB005421
  2. Create the Source and Destination endpoints. KB005427
  3. Purchase licenses. From your MSPComplete dashboard, click on Purchase > Mailbox Migration > select MigrationWiz-Mailbox and enter the number of licenses you wish to purchase. Check to see if there are any available bundles for discounts (e.g., MigrationWiz-Mailbox and DeploymentPro Bundle). KB004647
  4. Deploy DMA to users. Once DMA has been deployed to users, check the Users tab in MSPComplete. This will be populated with the user accounts that have DMA installed. DMA can be deployed by either of these options:
  5. Via Group Policy Object (GPO). Note: This is the recommended methodology, because no end user interaction is required. KB005412, KB005411

m6

Pre-stage Mailboxes

  1. Create the Mailbox Migration project. KB005070. Create the Mailbox Migration project > Select the customer > Select the Source endpoint > Select the Destination endpoint. Add the accounts (also referred to as “items”) that will be migrated to the project. KB004842
  1. Set the Project Advanced Options. KB004834
  • Set to use impersonation at the Destination. Checkmark the Use impersonation at Destination box. KB004727
  • Set Maximum concurrent migrations e.g. 500. If the Source server has enough server resources, set this parameter based on the bandwidth guideline of three (3) mailboxes per 1Mbps of bandwidth. Therefore, for example, if there is a 10Mbps connection, we recommend setting the maximum concurrent migrations parameter to be 30.
  • Set maximum error to 100.
  • Set successful and failed migration report to migrationadmin@company.com . Do not send a report to end user. This may cause confusion among users when you run credential checks and run pre-stage.
  1. Select the Project> Bulk Add using CSV file. CSV Headers

Source Email,Source Login Name,Source Password,Destination Email,Destination Login Name,Destination Password,Flags

Note: Since MigrationWiz has full access rights to source email and destination email. There is no need to populate password on the password column.

m3

 

 

 

 

 

  1. Run Verify Credentials for all mailboxes. KB004511
  2. Notify users that a migration is occurring. Send email to all users telling them the time and date of the migration.
  3. Pre-Stage pass: Select the users > Click on the Start button from the top, and select Pre-Stage Migration > Under the Migration Scheduling section, from the drop-down list, select 30 days ago > Click on Start Migration. KB004938
  4. If you notice any failed migration, just filter those failed migration> Pause Failed Migration. Select all Paused migration>Pre-stage all paused migration to complete migration simultaneously instead of waiting for migration to complete and retry error.

m2   m5

 

 

 

 

 

 

 

 

 

Final Migration or MX Cutover

  1. MX Record Cutover. Change over MX records on the DNS provider’s portal. Also include the AutoDiscover (CName) setting.
  2. Full (Delta) pass: Select the users > Click on the Start button from the top, select Full Migration > Click on Start Migration. KB004938
  3. Run Retry Errors. KB004658
  • Look through the user list and click on any red “failed migration” errors. Review information and act accordingly.
  • If problems persist, contact Support. KB004529
  • If not using DeploymentPro, users must create new Outlook profiles, and set up their signatures again, and reattach any PST files that were attached to their previous profile.
  1. Click on the pie chart icon in the MigrationWiz dashboard to receive an email containing all the project migration statistics. KB004626

Outlook Client Migration to new Office 365

DeploymentPro Steps

  1. Go to All Products > DeploymentPro and follow the prompts to launch.
  2. Select a customer from the list by clicking on the customer name. Note: The status column will show enabled when a customer account has had DMA deployed. Configure customer DeploymentPro module:
  • Enter Domain.
  • Select the Source endpoint.
  • Checkmark the Auto-populate box.

m4

 

 

 

Note: In the Client Interface Configurations section, upload your company logo and add supporting text. Note: We strongly recommend doing this, because this is the logo and text that end users will see in a desktop pop-up when they are prompted to reconfigure their Outlook profiles. If you do not upload your own logo, the default BitTitan logo will be included instead.

  1. Save and continue.
  2. Activate DeploymentPro module for users.
  3. Either select all users (by checkmarking the box to the left of the Primary Email column heading), or select the individual users (by checkmarking the boxes to the left of the user email addresses). Note: You will need to purchase DeploymentPro licenses for each user that will be using DeploymentPro. KB004647
  4. Click on the Run Module button.
  5. Schedule the profile cutover date.
  6. Set the date and time for the Outlook profile configuration to occur, and click on the Run Module button.

Notes:

  • The DeploymentPro module will install on user devices immediately, and then run silently until this date.
  • The profile cutover date should be set to a date and time that is shortly after MX record cutover.
  • On the profile cutover date, users will be guided through the reconfiguration of their Outlook profile.

References:

On-prem to Office 365 Migration: PowerShell Script Collection

On-Premises Exchange (versions 2007 and later) to Office 365 Migration Guide

Mailflow Co-existence between Hosted Mail and Office 365 during IMAP Migration

Mailflow Co-existence between G-Suite and Office 365 during IMAP Migration

This article will explain how to create mail flow coexistence between disparate IMAP source and Exchange Online destination.

Use case:

  1. Customer wants a mailflow co-existence between hosted email e.g. Gmail and Exchange Online during mailbox migration phase.
  2. Customer has on-premises Exchange Server but does not want to create hybrid environment or have a situation where hybrid configuration is not feasible.
  3. Customer plans to migrate mailboxes, calendar, contacts, resources and distribution groups to Exchange Online in phases.
  4. Customer does not want a cutover migration to Exchange Online.

Source Environment:

  1. Email Domain: Domain.com
  2. Migration Method: IMAP
  3. Source Infrastructure: On-premises Microsoft Exchange or Hosted Gmail

Destination Environment:

  1. Office 365 Tenant: domain.onmicrosoft.com
  2. Default Domain: domain.onmicrosoft.com
  3. Email Domain: Domain.com
  4. CatchAll Domain or Subdomain: subdomain.domain.com

Migration Method:

  • Pre-stage: In pre-stage migration, data will be pre-filled to a place holder mailbox then migrate delta changes.
  • Backfill: In backfill method, data will be back filled to a real mailbox after cutover.

Prepare Source Email Domain:

  1. Add Proxy address or alias to all mailboxes.

To add proxy address, create a CSV file with the below header and run the scripts

Name, EmailAddress

User1@domain.com, user1@domain.onmicrosoft.com

Import-Csv c:\data.csv | Foreach{

$maileg = Get-Mailbox -Identity $_.Name

$maileg.EmailAddresses += $_.emailaddress

$maileg | Set-Mailbox -EmailAddresses $_.emailaddress

}

  1. Create target address or forwarding address to all mailboxes. To add target address, create a CSV file with the below header and run the script

CSV Headers are Mailbox, ForwardTo

User1@domain.com, user1@domain.onmicrosoft.com

user1@domain.com, user1@subdomain.domain.com

Import-CSV “C:\CSV\Users.csv” | ForEach {Set-Mailbox -Identity $_.mailbox -ForwardingAddress $_.forwardto}

  1. Send & Receive Connector

If you have strict mailflow condition on the on-premises environment or hosted environment, you may have to create a send connector and receive connector to allow Office 365 email in both directions.

  1. MX record still pointed to source environment.

Prepare Exchange Online

  1. Create Office 365 tenant: domain.onmicrosoft.com
  2. Add customer domain e.g. domain.com on the Office 365 portal and validate the domain
  3. Go to Office 365 ECP, Select Mailflow, Click Accepted Domain, Select Domain.com, Click Edit and set the domain to Internal Relay
  4. Go to Office 365 ECP, Select Recipient, Go to Groups, Create a distribution group and add all users to the distribution group. To find a script to do the job, refer to step3 of post migration section of this article. replace remove-distributiongroupmember to add-distributiongroupmember on the script.
  5. Go to Office 365 ECP, Select Mailflow, Connectors, create an Outbound Send Connector to send email from Office 365 to Your organisation email server. When creating this Connector select the smart host option and on the smart host window, type the Public IP Address or FQDN of MX record of domain.com
  6. Go to Office 365 ECP, Select Mailflow, Rules, create a rule to forward any inbound emails coming to @domain.com and member of special distribution group created in step 4 to be forwarded to the send connector you have created in previous steps 5.
  7. Enable Mailflow for subdomain or catchall domain i.e. @subdomain.domain.com Set-AcceptedDomain -Identity domain.com -MatchSubdomains $true

Mailflow during migration phase

When an Exchange Online mailbox user1@domain send mail to user2@domain.com (On-premises/hosted Gmail), as user2 does not exist at Exchange Online side, and the domain: domain.com set as “Internal Relay” under “Accept domain” configuration, so the message will delivery to on-premises/Gmail through special outbound connector.

Post Migration:

Once you have migrated a batch of mailboxes, you have to remove proxy address and forwarding address from that batch of source mailboxes on the source email domain.

  1. Remove Proxy Address from Source Environment

CSV Headers are Name and EmailAddress

User1@domain.com, user1@domain.onmicrosoft.com

Import-Csv C:\CSV\ProxyAddress.csv | Foreach{

$maileg = Get-RemoteMailbox -Identity $_.Name

$maileg.EmailAddresses += $_.emailaddress

$maileg | Set-Mailbox -EmailAddresses @{Remove=$_.EmailAddress} }

 

  1. Remove Forwarding address from Source Environment

CSV headers are Mailbox, ForwardTo

User1@domain.com, user1@domain.onmicrosoft.com

Import-CSV “C:\CSV\Users.csv” | ForEach {Set-Mailbox -Identity $_.mailbox -ForwardingAddress @{Remove=$_.forwardto}}

  1. Remove the batch of mailboxes from the distribution groups once migrated to Office 365.

CSV Headers are

Identity, Members

Accounts, user1@domain.com

Import-Csv “C:\CSV\RemoveMembers.csv” | foreach{Remove-DistributionGroupMember -Identity $_.identity -Member $_.members}

  1. Delete special Distribution Group, Maiflow rule and Outbound Connector created on the step 4, step 5 and step 6 after MX record cutover to Office 365.