IaaS – Tunecom

How to monitor Azure Migrate replication issues

admin.yannickd — Mon, 25 Jan 2021 18:32:53 +0000

When migrating virtual or physical servers to Microsoft Azure with Azure Migrate you would like to monitor replication health.

Azure Migrate does provide a built-in solution for this within the Azure Migrate project(s). You can manually review the status or use PowerShell to retrieve the replication health of your IaaS machines. However, this lacks some kind of notification or alerting mechanism.

If you’re interested in how to automatically get notified when something goes wrong, please continue reading below.

A look under the hood of Azure Migrate

When looking at the bundle of products included in an Azure Migrate project, one key product is Azure Site Recovery (ASR) which is part of Recovery Services Vault.

Azure Site Recovery is used to replicate your origin machines to Azure.
This means that when we encounter any replication issues, we will have to look at our replication product in place.

When browsing the Recovery Services Vault blade, scroll down to the “Monitoring” section and select “Site Recovery Events“

On the “Site Recovery Events” page you will see a very similar page as displayed in the Azure Migrate Events page. Select “E-mail Notifications“

Enable the “E-mail notifications” by selecting On, select “Other administrators” if you want to set up alerts to non-Azure Services admins/co-admins. Enter an e-mail address and select save.

Whenever a new site recovery event or alert is triggered you will receive a mail notification.

Powershell

#Select your Azure Site Recovery Services Vault
$rsv = Get-AzRecoveryServicesVault | Out-GridView -OutputMode Single

#Set the recovery services vault context
Set-AzRecoveryServicesAsrVaultContext -Vault $rsv

#Retrieve current alerting configuration
Get-AzRecoveryServicesAsrAlertSetting

#Set alerts (Remove -EnableEmailSubscriptionOwner if you do now want the default owners to be notified)
$EmailAddressess = "test.test@test.be"
Set-AzRecoveryServicesAsrAlertSetting -CustomEmailAddress $EmailAddressess -EnableEmailSubscriptionOwner

Thank you!

Thank you for reading through this blog post, I hope I have been able to assist in your Azure Migration journey.

If you encounter any new insights, feel free to drop me a comment or contact me via mail or other social media channels

The post How to monitor Azure Migrate replication issues appeared first on Tunecom.

How to clean up replica disks after VMWare Virtual Machine migration with Azure Migrate

admin.yannickd — Wed, 06 Jan 2021 11:08:32 +0000

During the lifecycle of an Azure IaaS migration project with Azure Migrate, it is advised to perform some additional cleanup actions once you have migrated a certain set of virtual machines.

The migration process

The following migration process is usually followed when migrating VMWare VM’s to Azure IaaS VM’s with Azure Migrate.

Deploy Azure Migrate appliance
Run Discovery Assessment
Verify Application Dependency
Create server migration groups
Start replication with associated replication parameters
Perform test migration
Cleanup test migration
Perform final migration
Cleanup obsolete ASR disks!

Step 5 demystified – start replication

Starting as of step 5, the Azure Migrate appliance will be using Azure Site Recovery to start replicating your on-premises VMDK (virtual disk) files to the Subscription & Resource Group that you have selected in the migration settings.

Azure Site Recovery Disks

As you can see, a specific naming convention is applied by default to the ASR disks.

asrseeddisk-(VMName)-GUID

Step 6 demystified – run test migration

Once the initial delta sync of your virtual machine has been completed, you are now able to perform a test migration.

There are multiple reasons why you should perform a test migration, a major one is to find out if your server and corresponding applications are working properly in Azure.

During the test migration, a snapshot is taken of the ASR disks and a new virtual machine is being created based upon your migration settings.

Please note that your VM is being created with a “test” suffix, to indicate that this machine is being “test migrated”.

The virtual disk names can be altered in the migration settings pane, however, it is advised to keep the disk names as is, to avoid any confusion.

At this point, you will have 3 replica sets of your virtual machine disks.

The source on-premises VMDK files
The replication Azure Site Recovery disks
The target Azure Virtual Machine disks

Step 7 demystified – clean up test migration

Once you’ve confirmed that your virtual machine is Azure capable and corresponds to your needs, you can clean up the test migration.

Before cleaning up the test migration, make sure that you have documented or automated the steps that you have performed on this virtual machine. All changes made on the “test migration” Virtual Machine will be lost.

When performing a clean up of the test migration, the virtual machine and corresponding managed disks are being deleted.

Step 8 demystified – Perform final migration

During the final migration step, a final sync of the on-premises virtual machine will be made.

It is advised to mark the “shutdown local machine” option when performing the migration, this ensures that no data is being altered on the machine which is being migrated

Like the test migration step, a new virtual machine is being created based on a snapshot of the latest version of the ASR disks. Once the migration has been completed. Make sure to validate the server en perform the necessary actions that you have performed during the test migration.

Your new virtual machine name will now have the exact naming convention as your on-premises virtual machine, including the attached virtual disks.

Step 9 demystified – Clean up ASR disks

When looking at your Azure Migrate project, you will find a mix of servers that have been migrated and/or are pending a test migration or clean up.

When browsing to your VM in Azure Migrate, select disks. Note down the replica disk names, these are the replica disks that are still stored as a managed disk within your target resource group.

To clean up the ASR disks, make sure to stop the replication as soon as your migration has been completed.

After having stopped the replication, the managed disks are deleted from your resource group.

Automation Script

Below script can be used in order to automate the clean up of migrated virtual machines.

#Migration Project Input Variables
$AzMigrateProjectName = "project name here"
$AzMigrateSubscriptionID = "subscription id here"
$AzMigrateResourceGroupName = "resource group name here"

#Required Modules
Write-Output "Required modules loading"
#Requires -Modules @{ ModuleName="Az.Accounts"; ModuleVersion="2.2.3" }
#Requires -Modules @{ ModuleName="Az.Migrate"; ModuleVersion="0.1.1" }

Import-Module Az.Accounts
Import-Module Az.Migrate

#Account Login
Disconnect-AzAccount
Login-AzAccount

Set-AzContext -SubscriptionId $AzMigrateSubscriptionID

#Clean up
$MigrationProject = Get-AzMigrateProject -Name $AzMigrateProjectName -SubscriptionId $AzMigrateSubscriptionID -ResourceGroupName $AzMigrateResourceGroupName

$MigrationStatus = Get-AzMigrateServerReplication -ResourceGroupName $AzMigrateResourceGroupName -ProjectName $AzMigrateProjectName -SubscriptionId $AzMigrateSubscriptionID | Where-Object {$_.MigrationState -eq "MigrationSucceeded"} | select MachineName, MigrationState, AllowedOperation, Id

foreach ($migrationobject in $MigrationStatus) {
    $ObjectID = Get-AzMigrateServerReplication -TargetObjectID $migrationobject.id
    Write-host "Following replication job will be removed: " $migrationobject.MachineName -foregroundcolor green
    Remove-AzMigrateServerReplication -InputObject $ObjectID
}

Thank you!

Thank you for reading through this blog post, I hope I have been able to assist in keeping your Azure Migration journey as lean and mean as possible.

If you encounter any new insights, feel free to drop me a comment or contact me via mail or other social media channels

The post How to clean up replica disks after VMWare Virtual Machine migration with Azure Migrate appeared first on Tunecom.

How to fix “The Azure Migrate unified appliance is in a disconnected state, Ensure that the appliance is running and has connectivity before proceeding” issue

admin.yannickd — Mon, 04 Jan 2021 14:05:24 +0000

When re-hosting or migrating traditional IaaS servers located on VMWare you might encounter one of the following issues when trying to setup your replication towards Azure.

The case

You have a single Azure Migrate appliance, which you have used to perform the suitability analysis and you’ve enabled the same appliance in the migration project as well.

Which means that we will be targeting an agentless migration.

The issue

The Azure Migrate Virtual Appliance ‘appliance name’ is in a disconnected state, please verify network connectivity.

The resolution

The following troubleshooting steps should help you resolve this issue.

Step 1: Verify agent health on the appliance

Step 2: Re-run the configuration wizard and verify your settings

Step 3: Re-enter your Azure Credential

Step 4: Restart de replication and gateway services

Run the following commands in an administrative powershell or cmd prompt.

Net Stop asrgwy
Net Start asrgwy
Net Stop dra
Net Start dra

Step 5: Verify service health

Check your connection status in the Appliances blade of the Azure Migrate resource on the Azure Portal.

Ready to migrate

Thank you!

Thank you for reading through this blog post, I hope I have saved you some time on researching the disconnected state issue.

If you encounter any new insights, feel free to drop me a comment or contact me via mail or other social media channels

The post How to fix “The Azure Migrate unified appliance is in a disconnected state, Ensure that the appliance is running and has connectivity before proceeding” issue appeared first on Tunecom.

Virtual Datacenter Concept | Introduction

admin.yannickd — Tue, 31 Dec 2019 09:18:32 +0000

This blogpost is part of a series of Azure Virtual Datacenter Concept blog posts.

The following series of posts is a direct reference to the Virtual Datacenter Concept provided by Microsoft as part of the Cloud Adoption Framework.

My intention is to provide you with a holistic overview, lessons learned and best practices over the last couple of years during the design and implementation phase of the Azure Virtual Datacenter.

What is the Azure Virtual Datacenter Concept (VDC)?

VDC is a series of guidelines that can be interpreted in various ways, the main goal of the VDC is to be able to deploy and manage your Azure resources in a secure and proper fashion.

When looking at AzOps and AzSec we are striving to build an operational and security model that fits the customers needs and wishes, which can still provide the promised scalability, flexibility and cloud optimization benefits. AzOps and AzSec should play a supporting role in the application landscape

Taking into account the perspective of DevOps and DevSecOps the VDC should facilitate the application development team to perform CI/CD in a way that the entire IT infrastructure which is oriented around your Line-of-business applications closes the gap between the operations and deployment lifecycle.

Why should the Virtual Datacenter Concept matter to you?

Planning Cloud Adoption is key, we’ve often seen Cloud environments that have been setup with no clear vision of the future application and IT landscape, which ended up in consuming a lot of credits that could’ve been spent more wisely.

On your road to onboarding IaaS, PaaS and SaaS the Virtual Datacenter Concept is your hitchhikers guide to the galaxy. It’s often seen as a way to easily lift and shift your servers, when looking at the VDC from a broader perspective, it can be a good fit to start transitioning to PaaS and SaaS.

How does this all translate into practice?

Below infographic shows a typical scenario where a DTAP (Development, Test, Acceptance, Production) environment has been setup and during deployment, key components have gone missing.

In order to fix the above situation, we’ve got a couple of options, either deploy additional equipment on Azure or consolidate and optimize to make the best use of all Azure Resources.

Below IaaS overview shows how we can consolidate the central shared services and make use of unique Azure techniques like vnet peering to tie everything together in a secure way.

Extending your services to Azure

In the above example we’ve seen a full blow DTAP environment located on Azure infrastructure. However Cloud Adoption isn’t about moving virtual machines to the Cloud. When moving to the cloud our goal is to provide our end-customers with tools and applications that are always on and can meet the necessary capacity demands.

As a start we would primordially get started with the Virtual Datacenter Basic setup. This allows you to extend your on-premises workloads to Azure with a minimum amount of resources.

The basic setup consists of :

Hybrid cloud identity which can be setup in various ways that suits your business needs.
Virtual Private network connectivity based on Azure Virtual Network gateway
Resource Governance
Backup and business continuity additions

What’s next?

Hope you liked the introduction, and sort of know where we are working towards in this blogpost series.

The following aspects of the virtual datacenter concept will be highlighted in the following upcoming posts:

Virtual Datacenter Concept – 1 of 10- Naming Conventions
Virtual Datacenter Concept – 2 of 10 – Governance
Virtual Datacenter Concept – 3 of 10 – Resource Groups
Virtual Datacenter Concept – 4 of 10 – Virtual Networking
Virtual Datacenter Concept – 5 of 10 – Cloud Storage
Virtual Datacenter Concept – 6 of 10 – Identity Options
Virtual Datacenter Concept – 7 of 10 – Log Analytics
Virtual Datacenter Concept – 8 of 10 – Security
Virtual Datacenter Concept – 9 of 10 – Business Continuity
Virtual Datacenter Concept – 10 of 10 – Automation

The post Virtual Datacenter Concept | Introduction appeared first on Tunecom.