Move or Add a VM’s Primary NIC from one VNET to another vNet

In this example, the powershell Cmdlets edit the VM NIC properties and change the subnet from one vNet to another vNet.

Step1: Get Azure VM, NIC and Resource Group Properties.

Stop-AzVM -Name “vm” -ResourceGroupName “RG01”

$vm = Get-AzVm -Name “vm” -ResourceGroupName “RG01”
$myVnet = Get-AzVirtualNetwork -Name “VNET” -ResourceGroupName “RG01”
$backEnd = $myVnet.Subnets | ?{$_.Name -eq ‘Prod’}

# Create a virtual NIC
$myNic3 = New-AzNetworkInterface -ResourceGroupName “RG01” -Name “vNIC-01” -Location “AustraliaEast” -SubnetId $backEnd.Id

# Get the ID of the new virtual NIC and add to VM
$nicId = (Get-AzNetworkInterface -ResourceGroupName “RG01” -Name “vNIC-01”).Id
Add-AzVMNetworkInterface -VM $vm -Id $nicId | Update-AzVm -ResourceGroupName “RG01”

Step2 : Setup Values of Target vNet to be applied to the Azure VM

$vm.NetworkProfile.NetworkInterfaces

# Set NIC 0 to be primary
$vm.NetworkProfile.NetworkInterfaces[0].Primary = $true
$vm.NetworkProfile.NetworkInterfaces[1].Primary = $false

Step3: Apply the changes. The VM will be restarted once you execute the PowerShell command.

# Update the VM state in Azure
Update-AzVM -VM $vm -ResourceGroupName “RG01”

Start-AzVM -ResourceGroupName “RG01” -Name “vm”

Step4: Check the properties of the Azure VM.

Migration from Office 365 or Microsoft 365 mailboxes to G Suite using the G Suite Data Migration Service

Supported Environment

Microsoft 365, Office 365, Exchange 2016, 2013, 2010, 2007 or 2003.

Supported G Suite

G Suite Enterprise, Business, Basic, and Education accounts

G Suite Cost

Standard prices are shown. Google occasionally offers special discounts to some customers for both the Flexible and Annual Plan.

 Flexible PlanAnnual Plan
CommitmentNone1 year of service for licenses purchased at the start of the contract.
Billing cycle MonthlyMonthly
Monthly paymentG Suite Basic: USD 6 per user
G Suite Business: USD 12 per user
G Suite Enterprise: USD 25 per user
G Suite Basic: USD 6 per license
G Suite Business: USD 12 per license
G Suite Enterprise: USD 25 per license
Yearly totalG Suite Basic: USD 72 per user
G Suite Business: USD 144 per user
G Suite Enterprise: USD 300 per user
G Suite Basic: USD 72 per license
G Suite Business: USD 144 per license
G Suite Enterprise: USD 300 per license
Add usersAt any time for additional monthly costAt any time for additional monthly cost
Remove usersAt any time (reduces monthly cost)Only when you renew the annual contract. Until then, you pay for all purchased licenses.
Cancel serviceAt any time without a penaltyMust pay annual commitment (even if you cancel early).

Outlook requirements

Step1: Setup G Suite

To setup G Suite, you need three basic information and privilege to prove ownership of your domain.

  • Primary domain, e.g. mydomain.com
  • Verify Domain. When you sign up for G Suite, you can choose which type of verification record such as TXT, CNAME, MX record you want to use in the Setup Wizard.
  • personal username such as user1@mydomain.com
  • An email address which can be gmail email and can be changed later.

G Suite MX setup for your domain host

  1. Sign in to your domain’s account at your domain host.
  2. Need help? Contact your domain host’s Support team. Domain hosts are experts with MX records, and setup is a common task.
  3. Go to the section where you can update your domain’s MX records. It might be called something like “DNS Management,” “Mail Settings,” or “Advanced Settings.”
  4. Delete any existing MX records.
    If you can’t delete the existing records, change their priority number to 20 or higher.
  5. Add new MX records for the Google mail servers.

If your domain host limits the number of MX records, just add the first 2 records in this table.

Values for G Suite MX records

Name/Host/Alias Time to Live (TTL*) Record Type Priority Value/Answer/Destination
@ or leave blank 3600 MX 1 ASPMX.L.GOOGLE.COM.
@ or leave blank 3600 MX 5 ALT1.ASPMX.L.GOOGLE.COM.
@ or leave blank 3600 MX 5 ALT2.ASPMX.L.GOOGLE.COM.
@ or leave blank 3600 MX 10 ALT3.ASPMX.L.GOOGLE.COM.
@ or leave blank 3600 MX 10 ALT4.ASPMX.L.GOOGLE.COM.
  • Skip this step if you already verified your domain by another method (such as TXT record, HTML file, or meta tag).
  • Save your changes.

Step2: Test G Suite Email

  1. Sign in to admin.google.com with your G Suite username and password. 
  2. In the top right corner, click the App Launcher, Mail.

Step3 (optional): Setup Google Cloud Directory Sync (GCDS)

Setup Directory Sync to use existing authentication or on-premises Windows Domain Controller users.  With Google Cloud Directory Sync (GCDS), you can synchronize the data in your Google domain with your Microsoft® Active Directory® or LDAP server. Your Google users, groups, and shared contacts are synchronized to match the information in your LDAP server. 

Systems Requirements:

  1. Download GCDS
  2. A Google domain.
  3. Access to a Google domain super administrator account to authorize GCDS.
  4. Microsoft® Windows® (supported on Windows 7, Windows 8, Windows 10, Windows Server 2008/2012/2016).
  5. Linux®—If you’re using a 32-bit version of GCDS on a 64-bit Linux system, a 32-bit libc (such as libc6-i386) must be installed.
  6. Administrator access to your Google domain.
  7. LDAP administrator access to your directory server and familiarity with its contents as well as familiarity with the LDAP query language.
  8. Network administrator privileges and familiarity with your network and security settings for internal and outbound traffic.

Enable Authentication in Google Configuration Manager in Google Domain

Authorize access using OAuth

  1. Open Configuration Manager and click the Google Domain Configuration page.
  2. Click Authorize Now to set up your authorization settings and create a verification code.
  3. Click Sign In to open a browser window and sign into your Google domain with your super administrator username and password.
  4. Copy the token that’s displayed.
  5. In the Verification Code field, enter the token and click Validate.

Allow API Access in Google Admin Console

  1. Sign in to your Google Admin console.
  2. Sign in using your administrator account (does not end in @gmail.com).
  3. From the Admin console Home page, go to Security>API reference.
  4. To see Security on the Home page, you might have to click More controls at the bottom.
  5. Make sure the Enable API access box is checked.
  6. At the bottom, click Save.

Configure GCDS

  1. The simplest way to configure GCDS is to record credentials for Google Domain, On-premises Active Directory.
  2. Connect Google Domain and On-premises Active Directory
  3. Test connection
  4. Select an Organizational unit of Active Directory to Sync to Google Domain
  5. You’re done.

Step4: Assign Licenses

On the Licenses page of Configuration Manager, set up the GCDS license synchronisation for users in your Google domain.

If you have purchased different product SKUs for your domain, you may want to disable auto license assignment and use the GCDS license synchronisation feature to manage licenses for your Google user accounts. You should manage user license assignment using a single method. Either assign and manage product licenses through the Admin console or use the GCDS license synchronisation feature described here.

Additional Guide:

Step5 (optional): Setup Mailflow Co-existence between Office 365 and G Suite

Follow this guide to setup mailflow co-existence between Office 365 and G Suite.

Step6: Migrate email from Microsoft Exchange or Office 365

  1. Sign in to your Google Admin console.
  2. . Sign in using your administrator account (does not end in @gmail.com).
  1. From the Admin console Home page, go to Data migration. To see Data migration, you might have to click More controls at the bottom.
  2. Select the Email option and click Continue.
  3. On the Email Migration screen:
    1. From the Migration source list, select the Microsoft Exchange or Office 365 mail server that matches your legacy environment (where you’re migrating from). 
    2. Select the connection protocol of the legacy mail server by choosing an option:
      • To automatically determine the protocol, select Autoselect (Recommended).
      • To specify the Exchange Web Services URL for your legacy service, select Exchange Web Services and type the URL. The URL is the is the address that Exchange uses to communicate with Exchange Web Services, for example, https://outlook.office365.com/EWS/Exchange.asmx.
    3. Enter the email address and password for your role account.  
  4. Click Connect
  5. (Optional) If the connection fails, verify that the role account and connection protocol information is correct. Then, click Connect again. 
  6. In the Migration start date and Migration options sections, accept the default options or choose to exclude data that doesn’t need to be migrated. 
  7. Click Select Users.

Step7: Migrate a test email for a single user

  1. Complete the steps to set up the data migration service.
  2. Hover over Add and click Select user .
  3. In the Migrate From field, enter the user’s Exchange email address.
  4. In the Migrate To field, start typing the user’s new G Suite email address and choose from the list of suggested users. 
  5. Click Start.
  6. (Optional) To migrate another user’s email, repeat these steps. 
  7. To exit a completed migration, click Settings > Exit migration

Step8: Migrate email for multiple production users

  1. Complete the steps to set up the data migration service.
  2. Hover over Add and click Select multiple users.
  3. Click Attach File to upload a CSV file containing the legacy email addresses and the new G Suite email addresses. For details on how to format the file, see Use CSV files with the data migration service.
  4. Click Upload and start the migration.
  5. If there are errors in your file, choose an option:
    • To update the file, click Cancel, fix the file, and reload the updated file.
    • To ignore the incorrect mappings, check the Ignore errors box.

Notes: Formatting the CSV files

You can use a spreadsheet application, such as Google Sheets or Microsoft Excel®, or a text file to create the CSV file. Data in your CSV file is case-sensitive: make sure to use the correct case for emails, passwords, usernames, and resources.

Don’t include headers or use commas to separate the fields. Use line breaks to separate each entry.

Example CSV File

john.doe@googledomain.com,john.doe@microsoftdomain.onmicrosoft.com,calender1

In this example, you’re migrating john.doe@microsoftdomain.onmicrosoft.com (office 365) to john.doe@googledomain.com (G Suite) with a calender1 of Office 365.

Amazon WorkSpaces : A Cost-effective Alternative to Windows Virtual Desktop

An Amazon WorkSpace is a cloud-based virtual desktop that can act as a replacement for a traditional desktop. A WorkSpace is available as a bundle of operating system, compute resources, storage space, and software applications that allow a user to perform day-to-day tasks just like using a traditional desktop.

Amazon Web Services (AWS) is a secure cloud services platform, offering compute power, database storage, content delivery and other functionality to help businesses scale and grow.

Monthly App Cost (Price Dated 06/08/2019):

Application Bundle Applications Additional Monthly Price
Default applications bundle Utilities Firefox, 7-Zip No additional charge
Plus applications bundle Microsoft Office Professional, Trend Micro Worry-Free Business Security Services, Firefox, WinZip Additional $15 per month

Compute cost sample (Price Dated 06/08/2019):

Compute Root Volume User Volume Monthly Pricing
4 vCPU, 16 GB Memory 80 GB 100 GB $104
8 vCPU, 32 GB Memory 80 GB 100 GB $154
8 vCPU, 15 GB Memory, 1 GPU, 4 GB Graphics Memory 100 GB 100 GB $880
16 vCPU, 122 GB Memory, 1 GPU, 8 GB Video Memory 100 GB 100 GB $1,228

Requirements:

AWS Virtual Private Cloud

  • Configure a VPC with Private Subnets and a NAT Gateway
  • Configure a VPC with Public Subnets

Ports

  • TCP/UDP 53 – DNS
  • TCP/UDP 88 – Kerberos authentication
  • UDP 123 – NTP
  • TCP 135 – RPC
  • UDP 137-138 – Netlogon
  • TCP 139 – Netlogon
  • TCP/UDP 389 – LDAP
  • TCP/UDP 445 – SMB
  • TCP 1024-65535 – Dynamic ports for RPC
  • TCP 443
  • TCP 80

Access Control

  • Grant IAM users permission to AWS Workspace

Internet Access

  • Allow ports 443 and 80 to 0.0.0.0/0

LDAP authentication

  • AD Connector — Use your existing on-premises Microsoft Active Directory. Users can sign into their WorkSpaces using their on-premises credentials and access on-premises resources from their WorkSpaces.
  • Microsoft AD — Create a Microsoft Active Directory hosted on AWS.
  • Simple AD — Create a directory that is compatible with Microsoft Active Directory, powered by Samba 4, and hosted on AWS.
  • Cross trust — Create a trust relationship between your Microsoft AD directory and your on-premises domain.

Task 1: Configure a VPC with Private Subnets and a NAT Gateway

Step 1: Allocate an Elastic IP Address

Allocate an Elastic IP address for your NAT gateway as follows. Note that if you are using an alternative method of providing internet access, you can skip this step.

  1. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
  2. In the navigation pane, choose Elastic IPs.
  3. Choose Allocate new address.
  4. On the Allocate new address page, choose Allocate and make a note of the Elastic IP address, then choose Close.

Step 2: Create a VPC. Create a VPC with one public subnet and two private subnets as follows.

  1. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
  2. In the navigation pane, choose VPC Dashboard.
  3. Choose Launch VPC Wizard.
  4. Choose VPC with Public and Private Subnets and then choose Select.
  5. Configure the VPC as follows:
    1. For IPv4 CIDR block, type the CIDR block for the VPC. For example, 10.0.0.0/16. For more information, see VPC and Subnet Sizing for IPv4 in the Amazon VPC User Guide.
    2. For VPC name, type a name for the VPC.
  6. Configure the public subnet as follows:
    1. For IPv4 CIDR block, type the CIDR block for the subnet.
    2. For Availability Zone, keep No Preference.
    3. For Public subnet name, type a name for the subnet (for example, WorkSpaces Public Subnet).
  7. Configure the first private subnet as follows:
    1. For Private subnet’s IPv4 CIDR, type the CIDR block for the subnet.
    2. For Availability Zone, select the first one in the list (for example, us-west-2a).
    3. For Private subnet name, type a name for the subnet (for example, WorkSpaces Private Subnet 1).
  8. For Elastic IP Allocation ID, choose the Elastic IP address that you created. Note that if you are using an alternative method of providing internet access, you can skip this step.
  9. Choose Create VPC. Note that it takes several minutes to set up your VPC. After the VPC is created, choose OK.

Step 3: Add a Second Private Subnet

In the previous step, you created a VPC with one public subnet and one private subnet. Use the following procedure to add a second private subnet.

  1. In the navigation pane, choose Subnets.
  2. Choose Create Subnet.
  3. For Name tag, type a name for the private subnet (for example, WorkSpaces Private Subnet 2).
  4. For VPC, select the VPC that you created.
  5. For Availability Zone, select the second one in the list (for example, us-west-2b).
  6. For IPv4 CIDR block, type the CIDR block for the subnet.
  7. Choose Yes, Create.

Step 4: Verify and Name the Route Tables. You can verify and name the route tables for each subnet.

  1. In the navigation pane, choose Subnets, and select the public subnet that you created.
    1. On the Route Table tab, choose the ID of the route table (for example, rtb-12345678).
    2. Select the route table. Type a name (for example, workspaces-public-routetable) and choose the check mark to save the name.
    3. On the Routes tab, verify that there is one route for local traffic and another route that sends all other traffic to the internet gateway for the VPC.
  2. In the navigation pane, choose Subnets, and select the first private subnet that you created (for example, WorkSpaces Private Subnet 1).
    1. On the Route Table tab, choose the ID of the route table.
    2. Select the route table. Type a name (for example, workspaces-private-routetable) and choose the check mark to save the name.
    3. On the Routes tab, verify that there is one route for local traffic and another route that sends all other traffic to the NAT gateway.
  3. In the navigation pane, choose Subnets, and select the second private subnet that you created (for example, WorkSpaces Private Subnet 2). On the Routes tab, verify that the route table is the private route table (for example, workspaces-private-routetable). If the route table is different, choose Edit and select this route table.

Task 2: Configure a VPC with Public Subnets (Optional if you have completed task 1)

Step 1: Create a VPC with one public subnet as follows.

  1. Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
  2. In the navigation pane, choose VPC Dashboard.
  3. Choose Launch VPC Wizard.
  4. Choose VPC with a Single Public Subnet and then choose Select.
  5. For IPv4 CIDR block, type the CIDR block for the VPC. We recommend that you use a CIDR block from the private (non-publicly routable) IP address ranges specified in RFC 1918. For example, 10.0.0.0/16. For more information, see VPC and Subnet Sizing for IPv4 in the Amazon VPC User Guide.
  6. For VPC name, type a name for the VPC.
  7. For Public subnet’s IPv4 CIDR, type the CIDR block for the subnet.
  8. (Optional) For Subnet name, type a name for the subnet.
  9. For Availability Zone, choose the first one in the list.
  10. Choose Create VPC. After the VPC is created, choose OK.

Step 2: Add a Second Public Subnet

In the previous step, you created a VPC with one public subnet. Use the following procedure to add a second public subnet and associate it with the route table for the first public subnet, which has a route to the internet gateway for the VPC.

  1. In the navigation pane, choose Subnets.
  2. Choose Create Subnet.
  3. For Name tag, type a name for the subnet.
  4. For VPC, select the VPC that you created.
  5. For Availability Zone, choose the second one in the list.
  6. For IPv4 CIDR block, type the CIDR block for the subnet.
  7. Choose Create. After the subnet is created, choose Close.
  8. Associate the new public subnet with the route table created for the first subnet as follows:
    1. Select the checkbox for the first subnet.
    2. On the Route Table tab, choose the ID of the route table.
    3. On the Subnet Associations tab, choose Edit subnet associations.
    4. Select the checkbox for the second subnet and choose Save.

Step 3: Assign the Elastic IP Address

You can assign Elastic IP addresses to your WorkSpaces automatically or manually. To use automatic assignment, see Configure Automatic IP Addresses. To assign Elastic IP addresses manually, use the following procedure.

  1. Open the Amazon WorkSpaces console at https://console.aws.amazon.com/workspaces/.
  2. In the navigation pane, choose WorkSpaces.
  3. Expand the row for the WorkSpace and note the value of WorkSpace IP. This is the primary private IP address of WorkSpace.
  4. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
  5. In the navigation pane, choose Elastic IPs. If you do not have an available Elastic IP address, choose Allocate new address and follow the directions.
  6. In the navigation pane, choose Network Interfaces.
  7. Select the network interface for your WorkSpace. Note that the value of VPC ID matches the ID of your WorkSpaces VPC and the value of Primary private IPv4 IP matches the primary private IP address of the WorkSpace that you noted earlier.
  8. Choose Actions, Associate Address.
  9. On the Associate Elastic IP Address page, choose an Elastic IP address from Address and then choose Associate Address.

Option 1: Launch a WorkSpace Using AWS Managed Microsoft AD

Step 1: Create an AWS Managed Microsoft AD Directory

First, create an AWS Managed Microsoft AD directory. AWS Directory Service creates two directory servers, one in each of the private subnets of your VPC. Note that there are no users in the directory initially. You will add a user in the next step when you launch the WorkSpace.

  1. Open the Amazon WorkSpaces console at https://console.aws.amazon.com/workspaces/.
  2. In the navigation pane, choose Directories.
  3. Choose Set up Directory, Create Microsoft AD.
  4. Configure the directory as follows:
    1. For Organization name, type a unique organization name for your directory (for example, my-demo-directory). This name must be at least four characters in length, consist of only alphanumeric characters and hyphens (-), and begin or end with a character other than a hyphen.
    2. For Directory DNS, type the fully-qualified name for the directory (for example, workspaces.demo.com).
    3. For NetBIOS name, type a short name for the directory (for example, workspaces).
    4. For Admin password and Confirm password, type a password for the directory administrator account. For more information about the password requirements, see Create Your AWS Managed Microsoft AD Directory in the AWS Directory Service Administration Guide.
    5. (Optional) For Description, type a description for the directory.
    6. For VPC, select the VPC that you created.
    7. For Subnets, select the two private subnets (with the CIDR blocks 10.0.1.0/24 and 10.0.2.0/24).
    8. Choose Next Step.
  5. Choose Create Microsoft AD.
  6. Choose Done. The initial status of the directory is Creating. When directory creation is complete, the status is Active.

Step 2: Create a WorkSpace

Now that you have created an AWS Managed Microsoft AD directory, you are ready to create a WorkSpace.

To create a WorkSpace

  1. Open the Amazon WorkSpaces console at https://console.aws.amazon.com/workspaces/.
  2. In the navigation pane, choose WorkSpaces.
  3. Choose Launch WorkSpaces.
  4. On the Select a Directory page, choose the directory that you created, and then choose Next Step. Amazon WorkSpaces registers your directory.
  5. On the Identify Users page, add a new user to your directory as follows:
    1. Complete Username, First Name, Last Name, and Email. Use an email address that you have access to.
    2. Choose Create Users.
    3. Choose Next Step.
  6. On the Select Bundle page, select a bundle and then choose Next Step.
  7. On the WorkSpaces Configuration page, choose a running mode and then choose Next Step.
  8. On the Review & Launch WorkSpaces page, choose Launch WorkSpaces. The initial status of the WorkSpace is PENDING. When the launch is complete, the status is AVAILABLE and an invitation is sent to the email address that you specified for the user.

Step 3: Connect to the WorkSpace

After you receive the invitation email, you can connect to your WorkSpace using the client of your choice. After you sign in, the client displays the WorkSpace desktop.

Note

When you are connected to your WorkSpace from a Windows or MacOS client, you can toggle the fullscreen display by using following command shortcuts:

  • Windows client: Ctrl+Alt+Enter
  • MacOS client: Control+Option+Return

To connect to the WorkSpace

  1. Open the link in the invitation email. When prompted, specify a password and activate the user. Remember this password as you will need it to sign in to your WorkSpace.
  2. When prompted, download one of the client applications or, for Windows WorkSpaces, launch Web Access. http://clients.amazonworkspaces.com/
  3. Start the client, enter the registration code from the invitation email, and choose Register.
  4. When prompted to sign in, type the user name and password for the user, and then choose Sign In.
  5. (Optional) When prompted to save your credentials, choose Yes.

Option 2: Launch a WorkSpace Using AD Connector (Hybrid Identity or On-prem User Identity using Windows Active Directory)

Step 1: Create an AD Connector

  1. Open the Amazon WorkSpaces console at https://console.aws.amazon.com/workspaces/.
  2. In the navigation pane, choose Directories.
  3. Choose Set up Directory, Create AD Connector.
  4. For Organization name, type a unique organization name for your directory (for example, my-example-directory). This name must be at least four characters in length, consist of only alphanumeric characters and hyphens (-), and begin or end with a character other than a hyphen.
  5. For Connected directory DNS, type the fully-qualified name of your on-premises directory (for example, example.com).
  6. For Connected directory NetBIOS name, type the short name of your on-premises directory (for example, example).
  7. For Connector account username, type the user name of a user in your on-premises directory. The user must have permissions to read users and groups, create computer objects, and join computers to the domain.
  8. For Connector account password and Confirm password, type the password for the on-premises user account.
  9. For DNS address, type the IP address of at least one DNS server in your on-premises directory.
  10. (Optional) For Description, type a description for the directory.
  11. Keep Size as Small.
  12. For VPC, select your VPC.
  13. For Subnets, select your subnets. The DNS servers that you specified must be accessible from each subnet.
  14. Choose Next Step.
  15. Choose Create AD Connector. It takes several minutes for your directory to be connected. The initial status of the directory is Requested and then Creating. When directory creation is complete, the status is Active.

Step 2: Create a WorkSpace

Now you are ready to launch WorkSpaces for one or more users in your on-premises directory.

  1. Open the Amazon WorkSpaces console at https://console.aws.amazon.com/workspaces/.
  2. In the navigation pane, choose WorkSpaces.
  3. Choose Launch WorkSpaces.
  4. For Directory, choose the directory that you created.
  5. Choose Next. Amazon WorkSpaces registers your AD Connector.
  6. Select one or more existing users from your on-premises directory. Do not add new users to an on-premises directory through the Amazon WorkSpaces console.  To find users to select, you can type all or part of the user’s name and choose Search or choose Show All Users. Note that you cannot select a user that does not have an email address.
  7. After you select the users, choose Add Selected and then choose Next Step.
  8. Under Select Bundle, choose the default WorkSpace bundle to be used for the WorkSpaces. Under Assign WorkSpace Bundles, you can choose a different the bundle for an individual WorkSpace if needed. When you have finished, choose Next Step.
  9. Choose a running mode for your WorkSpaces and then choose Next Step. For more information, see Manage the WorkSpace Running Mode.
  10. Choose Launch WorkSpaces. The initial status of the WorkSpace is PENDING. When the launch is complete, the status is AVAILABLE.
  11. Send invitations to the email address for each user. For more information, see Send an Invitation Email.

Step 3: Connect to the WorkSpace

You can connect to your WorkSpace using the client of your choice. After you sign in, the client displays the WorkSpace desktop.

  • Windows client: Ctrl+Alt+Enter
  • MacOS client: Control+Option+Return

To connect to the WorkSpace

  1. Open Google Chrome, browse http://clients.amazonworkspaces.com/
  2. When prompted, download one of the client applications or launch Web Access.
  3. Start the client, enter the registration code from the invitation email, and choose Register.
  4. When prompted to sign in, type the username and password for the user, and then choose Sign In.
  5. (Optional) When prompted to save your credentials, choose Yes.

Migrating Azure VM to AWS EC2 using AWS Server Migration Service

Requirements for Azure connector

The recommended VM size of Azure connector is F4s – 4 vCPUs and 8 GB RAM. Ensure that you have a sufficient Azure CPU quota in the region where you are deploying the connector.

  • A Standard Storage Account (cannot be Premium) under which the connector can be deployed.
  • A virtual network where the connector can be deployed.
  • Allow inbound port 443 within the connector’s virtual network or not to the the public internet to view the connector dashboard.
  • Outbound Internet access for AWS, Azure, and so on.

Operating Systems Supported by AWS SMS

  • Microsoft Windows Server 2003 R2 or later version
  • Ubuntu 12.04 or later
  • Red Hat Enterprise Linux (RHEL) 5.1-5.11 or later
  • SUSE Linux Enterprise Server 11 with SP1 or later
  • CentOS 5.1-5.11, 6.1-6.6, 7.0-7.6
  • Debian 6.0.0-6.0.8, 7.0.0-7.8.0, 8.0.0
  • Oracle Linux 5.10-5.11 with el5uek kernel
  • Fedora Server 19-21

Considerations for Migration Scenarios

  • A single Server Migration Connector appliance can only migrate VMs under one subscription and one Azure Region.
  • After a Server Migration Connector appliance is deployed, you cannot change its subscription or Region unless you deploy another connector in the new subscription/Region.
  • AWS SMS supports deploying any number of Server Migration Connector appliance VMs to support migration from multiple Azure subscriptions and Regions in parallel.

Migration Steps   

  • Step 1: Download the Connector Installation Script
  • Step 2: Validate the Integrity and Cryptographic Signature of the Script File
  • Step 3: Run the Script
  • Step 4: Configure the Connector
  • (Alternative Procedure) Deploy the Server Migration Connector Manually
  • Step 5. Replicate Azure VM to AWS EC2 instance

Step1: Download the PowerShell script and hash files from the following URLs:

    After download, transfer the files to the computer or computers where you plan to run the script.

Step 2: Validate the Integrity and Cryptographic Signature of the Script File

To validate script integrity using cryptographic hashes (PowerShell). Use one or both of the downloaded hash files to validate the integrity of the script file. To validate with the MD5 hash, run the following command in a PowerShell window:

        PS C:\Users\Administrator> Get-FileHash aws-sms-azure-setup.ps1 -Algorithm MD5

        To validate with the SHA256 hash, run the following command in a PowerShell window:

        PS C:\Users\Administrator> Get-FileHash aws-sms-azure-setup.ps1 -Algorithm SHA256

Compare the returned hash values with the values provided in the downloaded files, aws-sms-azure-setup.ps1.md5 and aws-sms-azure-setup.ps1.sha256.

Next, use either PowerShell or the Windows user interface to check that the script file includes a valid signature from AWS. To check the script file for a valid cryptographic signature (PowerShell)

PS C:\Users\Administrator> Get-AuthenticodeSignature aws-sms-azure-setup.ps1 | Select *

PS C:\Users\Administrator\Desktop\aws-sms-azure-setup.ps1

To check the script file for a valid cryptographic signature (Windows GUI). In Windows Explorer, open the context (right-click) menu on the script file and choose Properties, Digital Signatures, Amazon Web Services, and Details. Verify that the displayed information contains “This digital signature is OK” and that “Amazon Web Services, Inc.” is the signer.

Step 3: Run the Script

Run this script from any computer with PowerShell 5.1 or later installed.

PS C:\Users\Administrator> Set-ExecutionPolicy -ExecutionPolicy Undefined -Scope CurrentUser

PS C:\Users\Administrator> Set-ExecutionPolicy -ExecutionPolicy UnRestricted -Scope LocalMachine

PS C:\Users\Administrator> Connect-AzAccount

If you’re a Cloud Solution Provider (Azure CSP), the -TenantId value must be a tenant ID.

PS C:\Users\Administrator> Connect-AzAccount -TenantId ‘xxxx-xxxx-xxxx-xxxx’

PS C:\Users\Administrator> Connect-AzureRmAccount -Tenant “xxxx-xxxx-xxxx-xxxx” -SubscriptionId “yyyy-yyyy-yyyy-yyyy”

PS C:\Users\Administrator> .\aws-sms-azure-setup.ps1 -StorageAccountName name -ExistingVNetName name -SubscriptionId id -SubnetName name

StorageAccountName =  The name of the Azure storage account where you want to deploy the connector.

ExistingVNetName = The name of the Azure virtual network where you want to deploy the connector.

SubscriptionId = The ID of the subscription to use. The default subscription for the account is used.

SubnetName = The name of the subnet in the virtual network. The subnet named “default” is used.

Step 4: Configure the Connector

RDP to another VM on the same virtual network where you deployed the connector, use Google chrome browser  to the connector’s web interface using the following URL, https://ip-address-of-connector

  1. On the connector landing page, choose Get started now
  2. Review the license agreement, select the check box, and choose Next.
  3. Create a password for the connector. The password must meet the displayed criteria. Choose Next.
  4. On the Network Info page, you can find instructions to perform network-related tasks, such as setting up AWS proxy for the connector. Choose Next.
  5. On the Log Uploads page, select Upload logs automatically and choose Next.
  6. On the Server Migration Service page, provide the following information:
  7. For AWS Region, choose your Region from the list.
  8. For AWS Credentials, enter the IAM credentials that you created in Configure AWS SMS Permissions and Roles. Choose Next.
  9. On the Azure Account Verification page, verify that your Azure subscription ID and location are correct. This connector can migrate VMs under this subscription and location. Provide the object ID of the System Assigned Identity of the connector VM, which was provided as output from the deployment script.
  10. If you successfully set up the connector, the Congratulations page is displayed. To view the health status of the connector, choose Go to connector dashboard.
  11. To verify that the connector that you registered is listed, open the Connectors page on the Systems Manager console.

(Alternative Procedure) Deploy the Server Migration Connector Manually

Complete this procedure to install the connector manually in your Azure environment.

To install the connector manually

Log into the Azure Portal as a user with administrator permissions for the subscription under which you are deploying this connector.

Make sure that you are ready to supply a Storage Account, its Resource Group, a Virtual Network, and the Azure Region as described in Requirements for Azure connector.

Download the connector VHD and associated files from the URLs in the following table.

 Verify the cryptographic integrity of the connector VHD using procedures similar to those described in Step 2: Validate the Integrity and Cryptographic Signature of the Script File.

Upload the connector VHD and associated files to your Storage Account.

$resourceGroupName = “myResourceGroup”

$urlOfUploadedVhd = “https://mystorageaccount.blob.core.windows.net/mycontainer/myUploadedVHD.vhd”

Add-AzVhd -ResourceGroupName $resourceGroupName -Destination $urlOfUploadedVhd -LocalFilePath “E:\Virtual hard disks\myVHD.vhd”

Create a new managed disk with the following parameter values:

$sourceUri = “https://storageaccount.blob.core.windows.net/vhdcontainer/osdisk.vhd”

$osDiskName = “myOsDisk”

$osDisk = New-AzDisk -DiskName $osDiskName –Disk (New-AzDiskConfig -AccountType Standard_LRS -Location $location -CreateOption Import -SourceUri $sourceUri) -ResourceGroupName $destinationResourceGroup

 Where $SourceUri or Storage Blob (Choose the VHD blob you uploaded from step 3.c.)

Create a public IP address and NIC

Create the public IP. In this example, the public IP address name is set to myIP.

$ipName = “myIP”

$pip = New-AzPublicIpAddress  -Name $ipName -ResourceGroupName $destinationResourceGroup

   -Location $location  -AllocationMethod Dynamic

Create the NIC. In this example, the NIC name is set to myNicName.

$nicName = “myNicName”

$nic = New-AzNetworkInterface -Name $nicName -ResourceGroupName $destinationResourceGroup -Location $location -SubnetId $vnet.Subnets[0].Id -PublicIpAddressId $pip.Id -NetworkSecurityGroupId $nsg.Id

Set the VM name and size

$vmName = “myVM”

$vmConfig = New-AzVMConfig -VMName $vmName -VMSize “F4s”

$vm = Add-AzVMNetworkInterface -VM $vmConfig -Id $nic.Id

Add the OS disk

$vm = Set-AzVMOSDisk -VM $vm -ManagedDiskId $osDisk.Id -StorageAccountType Standard_LRS -DiskSizeInGB 128 -CreateOption Attach -Windows

Complete the VM

New-AzVM -ResourceGroupName $destinationResourceGroup -Location $location -VM $vm

Download the two role documents:

    Edit SMSConnectorRole.json. Change the name field to sms-connector-role-subscription_id. Then change the AssignableScopes field to match your subscription ID.

    Edit SMSConnectorRoleSA.json. Change the name field to sms-connector-role-storage_account. For example, if your account is testStorage, then the name field must be sms-connector-role-testStorage. Then change the AssignableScopes field to match your Subscription, Resource Group, and Storage Account values.

You must use Az CLI or Az PowerShell for this step.

PS C:\Users\Administrator> New-AzRoleDefinition -InputFile C:\Temp\roleDefinition.json

Assign roles to the connector VM. In Azure Portal, choose Storage Account, Access Control, Roles, Add, Add Role Assignment. Choose the role sms-connector-role, assign access to Virtual Machine, and select the connector VM’s System Assigned Identity from the list. Repeat this for the role sms-connector-role-storage_account.

Restart the connector VM to activate the role assignments.

Step 4: Configure the SMS Connector.

This step guides you to replicating Azure VMs Using the AWS SMS Console. Use the AWS SMS console to import your server catalog and migrate your Azure VMs to Amazon EC2. You can perform the following tasks:

  1. Replicate a server using the console
  2. Monitor and modify server replication jobs
  3. Shut down replication

To replicate a VM from Azure to AWS using the console

  1. Install the Server Migration Connector as described in Getting Started with AWS Server Migration Service, including the configuration of an IAM service role and permissions.
  2. In a web browser, open the SMS homepage.
  3. In the navigation menu, choose Connectors. Verify that the connector that you deployed in your Azure environment is shown with a status of healthy.
  4. If you have not yet imported a catalog, choose Servers, Import server catalog. To reflect new servers added in your Azure environment after your previous import operation, choose Re-import server catalog. This process can take up to a minute.
  5. Select a server to replicate and choose Create replication job.
  6. On the Configure server-specific settings page, in the License type column, select the license type for AMIs to be created from the replication job. Windows servers can only use Bring Your Own License (BYOL). Choose Next.
  7. On the Configure replication job settings page, the following settings are available:
  8. For Replication job type, choose a value. The One-time migration option triggers a single replication of your server without scheduling repeating replications.
  9. For Start replication run, configure your replication run to start either immediately or at a later date and time up to 30 days in the future. The date and time settings refer to your browser’s local time.
  10. For IAM service role, provide (if necessary) the IAM service role that you previously created.
  11. For Enable automatic AMI deletion, configure AWS SMS to delete older replication AMIs in excess of a number that you provide in the field.
  12. For Enable AMI Encryption, choose a value. If you choose Yes, AWS SMS encrypts the generated AMIs. Your default CMK is used unless you specify a non-default CMK. For more information, see Amazon EBS Encryption.
  13. For Enable notifications, choose a value. If you choose Yes, you can configure Amazon Simple Notification Service (Amazon SNS) to notify a list of recipients when the replication job has completed, failed, or been deleted.
  14. For Pause replication job on consecutive failures, choose a value. The default is set to Yes. If the job encounters consecutive failures, it will be moved to the PausedOnFailure state and not marked Failed immediately.
  15. Choose Next.
  16. On the Review page, review your settings. If the settings are correct, choose Create. To change the settings, choose Previous. After a replication job is set up, replication starts automatically at the specified time and interval.
  17. On the Replication jobs page, select a job and choose Actions, Start replication run. This starts a replication run that does not affect your scheduled replication runs, except in the case that the on-demand run is still ongoing at the time of your scheduled run. In this case, the scheduled run is skipped and rescheduled at the next interval. The same thing happens if a scheduled run is due while a previous scheduled run is still in progress.
  18. In the AWS SMS console, choose Replication jobs. You can view all replication jobs by scrolling through the table. In the search bar, you can filter the table contents on specific values. Filter the jobs by PausedOnFailure to identify all the paused jobs.
  19. After you have finished replicating a server, you can delete the replication job. Choose Replication jobs, select the desired job, choose Actions, and then choose Delete replication jobs. In the confirmation window, choose Delete. This stops the replication job and cleans up any artifacts created by the service (for example, the job’s S3 bucket). This does not delete any AMIs created by runs of the stopped job.
  20. Once Replication is complete, Pause the replication, Shutdown the Azure VM and Power on AWS EC2 instances.
  21. Once Migration is complete and when you are done using a connector and no longer need it for any replication jobs, you can disassociate it. Choose Connectors and select the connector to disassociate. Choose Disassociate at the top-right corner of its information section and choose Disassociate again in the confirmation window. This action de-registers the connector from AWS SMS.

Prepare Windows 10 Master Image & Deploy Windows Virtual Desktop

Microsoft announced Windows Virtual Desktop and began a private preview. Since then, we’ve been hard at work developing the ability to scale and deliver a true multi-session Windows 10 and Office 365 ProPlus virtual desktop and app experience on any device.

Windows Virtual Desktop will also be extended and enriched by leading partners in the following ways:

  • Citrix can extend Windows Virtual Desktop capabilities with their Citrix Cloud services.
  • Through our partnership with Samsung, Windows Virtual Desktop will provide highly mobile First line Workers access to a full Windows 10 and Office 365 ProPlus experience with Samsung DeX.
  • Software and service providers will extend Windows Virtual Desktop to offer targeted solutions in the Azure marketplace.
  • Microsoft Cloud Solution Providers (CSPs) will deliver end-to-end desktop-as-a-service (DaaS) offerings and value-added services to their customers.

Prepare Image

Prepare Windows 10 Ent Golden Image to be used for Windows Virtual Desktop in Azure Cloud. Execute the following steps on the Windows 10 Ent master image.

Step1: Remove Persistent Routing using this command, route delete

Step2: Remove Proxy Server using this Command, netsh winhttp reset proxy

Step3: Set the disk SAN policy to Onlineall using this command, diskpart then san policy=onlineall

Step4: Set time zone to Windows Automatic

Set-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Control\TimeZoneInformation’ -name “RealTimeIsUniversal” -Value 1 -Type DWord -force

Set-Service -Name w32time -StartupType Automatic

Step5: Setup Power Profile using this command powercfg /setactive SCHEME_MIN

Step6: Setup TEMP and TMP and location to default

Set-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Environment’ -name “TEMP” -Value “%SystemRoot%\TEMP” -Type ExpandString -force

Set-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Environment’ -name “TMP” -Value “%SystemRoot%\TEMP” -Type ExpandString –force

Step7: Setup Windows Services to automatic

Set-Service -Name bfe -StartupType Automatic

Set-Service -Name dhcp -StartupType Automatic

Set-Service -Name dnscache -StartupType Automatic

Set-Service -Name IKEEXT -StartupType Automatic

Set-Service -Name iphlpsvc -StartupType Automatic

Set-Service -Name netlogon -StartupType Manual

Set-Service -Name netman -StartupType Manual

Set-Service -Name nsi -StartupType Automatic

Set-Service -Name termService -StartupType Manual

Set-Service -Name MpsSvc -StartupType Automatic

Set-Service -Name RemoteRegistry -StartupType Automatic

Step8: Setup Remote Desktop registry

Set-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server’ -name “fDenyTSConnections” -Value 0 -Type DWord -force

Set-ItemProperty -Path ‘HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services’ -name “fDenyTSConnections” -Value 0 -Type DWord –force

Set-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-Tcp’ -name “PortNumber” -Value 3389 -Type DWord –force

Set-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-Tcp’ -name “LanAdapter” -Value 0 -Type DWord –force

Set-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp’ -name “UserAuthentication” -Value 1 -Type DWord -force

Set-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp’ -name “SecurityLayer” -Value 1 -Type DWord -force

Set-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp’ -name “fAllowSecProtocolNegotiation” -Value 1 -Type DWord –force

Set-ItemProperty -Path ‘HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services’ -name “KeepAliveEnable” -Value 1  -Type DWord -force

Set-ItemProperty -Path ‘HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services’ -name “KeepAliveInterval” -Value 1  -Type DWord -force

Set-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-Tcp’ -name “KeepAliveTimeout” -Value 1 -Type DWord –force

Set-ItemProperty -Path ‘HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services’ -name “KeepAliveEnable” -Value 1  -Type DWord -force

Set-ItemProperty -Path ‘HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services’ -name “KeepAliveInterval” -Value 1  -Type DWord -force

Set-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-Tcp’ -name “KeepAliveTimeout” -Value 1 -Type DWord –force

Set-ItemProperty -Path ‘HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services’ -name “fDisableAutoReconnect” -Value 0 -Type DWord -force

Set-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-Tcp’ -name “fInheritReconnectSame” -Value 1 -Type DWord -force

Set-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-Tcp’ -name “fReconnectSame” -Value 0 -Type DWord –force

Set-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-Tcp’ -name “MaxInstanceCount” -Value 4294967295 -Type DWord –force

Remove-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp’ -name “SSLCertificateSHA1Hash” –force

Step9: Setup Firewall

Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled True

Enable-PSRemoting -force

 Set-NetFirewallRule -DisplayName “Windows Remote Management (HTTP-In)” -Enabled True

Set-NetFirewallRule -DisplayGroup “Remote Desktop” -Enabled True

Set-NetFirewallRule -DisplayName “File and Printer Sharing (Echo Request – ICMPv4-In)” -Enabled True

Step10: Check VM disk on next boot

Chkdsk /f

Step11: Set the Boot Configuration Data (BCD) settings

 bcdedit /set {bootmgr} integrityservices enable

 bcdedit /set {default} device partition=C:

 bcdedit /set {default} integrityservices enable

 bcdedit /set {default} recoveryenabled Off

 bcdedit /set {default} osdevice partition=C:

 bcdedit /set {default} bootstatuspolicy IgnoreAllFailures

 #Enable Serial Console Feature

 bcdedit /set {bootmgr} displaybootmenu yes

 bcdedit /set {bootmgr} timeout 5

 bcdedit /set {bootmgr} bootems yes

 bcdedit /ems {current} ON

 bcdedit /emssettings EMSPORT:1 EMSBAUDRATE:115200

Step11: Setup Crash dump

# Setup the Guest OS to collect a kernel dump on an OS crash event

Set-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl’ -name CrashDumpEnabled -Type DWord -force -Value 2

Set-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl’ -name DumpFile -Type ExpandString -force -Value “%SystemRoot%\MEMORY.DMP”

Set-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl’ -name NMICrashDump -Type DWord -force -Value 1

#Setup the Guest OS to collect user mode dumps on a service crash event

$key = ‘HKLM:\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps’

if ((Test-Path -Path $key) -eq $false) {(New-Item -Path ‘HKLM:\SOFTWARE\Microsoft\Windows\Windows Error Reporting’ -Name LocalDumps)}

New-ItemProperty -Path $key -name DumpFolder -Type ExpandString -force -Value “c:\CrashDumps”

New-ItemProperty -Path $key -name CrashCount -Type DWord -force -Value 10

New-ItemProperty -Path $key -name DumpType -Type DWord -force -Value 2

Set-Service -Name WerSvc -StartupType Manual

Step12: Verify that the Windows Management Instrumentations (WMI) repository

winmgmt /verifyrepository

Step14: Do not remove or modify access for the following accounts

  • Administrators
  • Backup Operators
  • Everyone
  • Users

Step13: Install Azure VM Agents

Install the Azure VMs Agent.

Step14: Setup Pagefile to different location

Set-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management’ -name “PagingFiles” -Value “D:\pagefile.sys” -Type MultiString –force

Generalise Golden Image

  1. Boot a PC into Audit Mode. When Windows boots into Audit Mode, System Preparation Tool will appear on the desktop. You can choose to either close the System Preparation Tool window or allow it to remain open.
  2. Customize Windows by adding drivers, changing settings, and installing programs. Do not install any Microsoft Store apps using the Microsoft Store.
  3. Run Sysprep. %WINDIR%\system32\sysprep\sysprep.exe /generalize /shutdown /oobe

Convert disk using Hyper-V Manager

  1. Open Hyper-V Manager and select your local computer on the left. In the menu above the computer list, click Action > Edit Disk.
  2. On the Locate Virtual Hard Disk screen, locate and select your virtual disk.
  3. On the Choose Action screen, and then select Convert and Next.
  4. If you need to convert from VHDX, select VHD and then click Next.
  5. If you need to convert from a dynamically expanding disk, select Fixed size and then click Next.
  6. Locate and select a path to save the new VHD file to.
  7. Click Finish.
  8. You can do the same using PowerShell Convert-VHD –Path c:\test\MY-VM.vhdx –DestinationPath c:\test\MY-NEW-VM.vhd -VHDType Fixed

Export Windows 10 Enterprise VHD

  1. On Hyper-V Manager, right-click the virtual machine and select Export.
  2. Choose where to store the exported files, and click Export.
  3. When the export is done, you can see all exported files under the export location.

Upload VHD to Azure Blob Storage

You can also upload a VHD to your storage account using one of the following:

  • AzCopy
  • Azure Storage Copy Blob API
  • Azure Storage Explorer Uploading Blobs
  • Storage Import/Export Service REST API Reference
  • PowerShell

Use the Add-AzVhd cmdlet to upload the VHD to a container in your storage account.

$rgName = “myResourceGroup”

$urlOfUploadedImageVhd = “https://mystorageaccount.blob.core.windows.net/mycontainer/myUploadedVHD.vhd”

Add-AzVhd -ResourceGroupName $rgName -Destination $urlOfUploadedImageVhd

    -LocalFilePath “C:\Users\Public\Documents\Virtual hard disks\myVHD.vhd”

Create a managed image from the uploaded VHD

$location = “Australia East”

$imageName = “Windows10EntGoldImage”

$imageConfig = New-AzImageConfig -Location $location

$imageConfig = Set-AzImageOsDisk -Image $imageConfig -OsType Windows -OsState Generalized -BlobUri $urlOfUploadedImageVhd -DiskSizeGB 20

New-AzImage  -ImageName $imageName -ResourceGroupName $rgName –Image $imageConfig

Create the VM

New-AzVm -ResourceGroupName $rgName  -Name ” VM1″ -ImageName $imageName -Location $location -VirtualNetworkName “myVnet” -SubnetName “mySubnet” -SecurityGroupName “myNSG” -PublicIpAddressName “myPIP” -OpenPorts 3389

Deploy Windows Virtual Desktop Host Pool from the Azure Managed Image.

Use the below KBs to create Windows Virtual Desktop host pool.

KB1 and KB2. Follow the KBs except when selecting an image select Managed Image you created using above how to. 

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.