VM Migration: Consideration while using Azure Site Recovery (ASR)

Last few weeks, i spent good amount of time on testing Azure Site Recovery capabilities for performing migration. During testing few of the things, which came across me. Although Microsoft has tried best to document entire process, but sometime we, as human being, has tendency of missing critical part or things are not mentioned clear.

I am going jot down those which would help in planning, testing and using ASR for migration.

  • Configuration server should be as per recommended sizing. You can also perform with slightly lesser configuration also, but be cognizant of fact that you may not get good performance.
    • Save Recovery Vault Credential at secured and known place on Configuration server,
    • If using unmatched configuration, while installing Configuration Server Application (Unified Agent), you would receive compatibility assessment with Warning, Error etc. Warning can be read through and can be ignored.
    • You may require (most probably) machine restart. Please do that.
    • Configuration server set up with either Proxy or Without Proxy based scenario. So, security can be taken care as per enterprise rule.
  • V Imp. straight after installation of Microsoft Azure Site Recovery Configuration Server wizard , you should do two things;
    • Add Account of Target Source Server which you want to migrate. Key here is that those should be either Domain Admin account, who has right to install application on Source Server, OR Local Admin Account of target server.
      • Thus, if you have multiple server in environment and does not domain joined server, you may end up adding many account. Try to Add, user friendly name, which can be later identified easily.
    • After adding account, go to next tab of ‘Vault Registration’ Browser same Vault Registration Credential, which were used during installation. This might sound confusing and may not find in documentation. But, during my testing i found that it have impact. Even if you leave this option, your config server still be visible on ASR. But, discovery and mobility service push may not work as expected. Therefore, it is better to take precaution than rectifying later, which is off-course difficult.
    • Vault Regis
  • If trying to migrate Physical Server, you would need to add Physical Servers manually by their IP. Config server would not do auto-discovery unlike VMware or HyperV migration.
  • Target Source Server should have expected firewall rules enable. Follow Microsoft documentation for detail. Basically, you should have WMI, File/Print sharing necessary things are enabled at Source Protected VM. Failing to do so, neither you would be able to push install Mobility Service or Migrate Server.
  • Since ASR gives you option of perform Test Fail-over, Pre-Check before migration, always use “Test Fail-over” option. This help in checking if target destination server would perform as application behaving at source server.
    • Recommendation is to have ‘test network sub-net’ and test fail-over on it. Keep production separate.
  • If you have application running on Running has some dependency on different environment or source server or intranet application, it is recommended to keep your network layer ready prior initiating migration process. Set up Hybrid Network either using Site-to-Site or Express Route. Create different virtual network sub-net, testing/production etc. Testing should be performed only on Testing Sub-net.

This is for today. I would be collating more information about scenario we can touch base for ASR.

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s