14/04/2016 Pauwel Rummens

Automating Windows migrations to Aws with Double Take Move and Ansible

Intro

When you’re a cloud reseller/architect you often get contacted by customers who want to migrate their infra to Aws.

Although I’m not really for the lift and shift way of working, sometimes there is no way around it.

 

Instead of spending hours of work on installing and configuring, exporting, importing, etc… we can now really get things going by using Double Take Move and Ansible.

For this article you need some basic knowledge of Ansible.

A good place to start is (http://docs.ansible.com/ansible/ )

 

Double take move is really well made and very user friendly!

And the license cost to use this product is forgotten easily when you don’t have to spend hours in exporting-importing – troubleshooting these kind of moves.

(http://www.visionsolutions.com/products/windows/double-take-move/overview)

 

 

Prep work

Ah yes, there is always some prep work to do. (more if your not already using Ansible now)

AWS

Lets first configure the Aws environment, create the needed vpc, subnets,vpn’s, seurity groups, roles,etc…

VPC

Make sure that the vpc cidr block and subnets match your current setup exactly.

(And also create the target servers in the correct subnets)

DHCP option set

Make sure that you create a dhcp option set if the servers you are migrating are on dhcp.

Example:

 

Public ip’s

Maybe for connectivity to work you will need to attach some public ip’s to your source and target servers.

We used this mostly in Azure to Aws migrations.

 

Ansible Setup

We have been using Ansible for quite some time now and we find that installing it on Centos or Ubuntu is the best way to go.

Below are the basic steps for Centos

  • We mostly use at least Ansible version 2, therefore we need to enable the the epel-testing repository to install Ansible. Edit the file under /etc/yum.repos.d/epel-testing.repo to enable it. Then run the below commands

 

Accept defaults for the keygen. Or change to your way of working (you can then push this key out to linux server, which are not in scope of this blog)

  • Install pywinrm

  • If your windows systems are in a domain (most of them normally are) install the Kerberos dependencies

  • You will also need the python part to this

 

Please read the kerberos documentation carefully, as your really need this to be correct and working.

 

Kerberos

Edit the /etc/krb5.conf file and change it to reflect your domain

 

 

When that is done you can test the connection is working by running the below command

 

 

If nothing is returned -> don’t panic!!! Then it worked !

You can then check your Kerberos ticket with the command

 

 

Inventory

Under your /etc/ansible directory there is a hosts file.

It contains some examples in how to use an Ansible Inventory file.

Create yours any way you like.

But for the these migration you can do something like this

 

 

For each group you create here you can/must create a credential file with the same name.

So in this case a sourceservers.yml and targetservers.yml

Store these under the /etc/ansible/group_vars.

Content of these files for local users

 

 

Content of the file for domain users

 

 

You can also add it in the hosts file like so

 

 

Windows Configuration

Make sure your target servers are as identical as possible to your source servers.

So same os ,service pack,IP and disk layout and your good to go. (ooh and don’t rename your target server to the source server just yet, double take will complain and will not continue. But a usefull name is a good way to identify the target server)

You will need to do the below on all source and target servers, for the target servers you can maybe create an ami from which to deploy, depending in how many servers you need to migrate.

  • Configure winrm on all windows machines that you need to migrate (script for this can be found here : http://docs.ansible.com/ansible/intro_windows.html
  • Also make sure you have at least version 3 of powershell installed, so basically check all your servers that are below server 2012.
  • Preferably create an “ansible” user on those systems and allow it to connect through winrm (there is a local group called WinRMRemoteWMIUsers__, add it to this group. Also the local admin, else you will not be able to do everything that is needed here)
  • Because of Ansible’s way of spawning allot of connections I found that increasing the MaxShellsPerUser parameter for winrm to give less problems.

Command :

Hint: You can combine the above in the ConfigureRemotingForAnsible.ps1 that you download from the ansible site, by added the following on the bottom of the script

I found that in most cases you will need to reboot the server in order for it all to work correctly.

 

Firewalls

Ofcourse we need to modify some firewall rules here and there.

Make sure that ansible can reach your servers on 5986 tcp.

Also make sure that source and target servers can speak with each other directly over port 6320 and 6325 tcp and udp.

The double take console will also need to speak with all servers on these ports.

 

Note: ofcourse make sure that all other needed rules,routes,vpn’s,etc are in place for your servers.

 

Test test test

We can now test the connection to the windows servers.

(If you are using the domain credentials make sure you have a valid Kerberos ticket first.)

Run the following

to verify the source server connections

to verify the target server connections

 

Double take console

I’m not going to go into details here but on the machine you have installed the double take console you add all the servers (source and target), attach the licenses to them and setup full server replication jobs with the parameters of your choice.

Wait before failing over, we will need some more playbooks depending on your server licensing.

 

Playbooks

On to the interesting stuff, unless you want to manually install double take software on all servers then go do that now 🙂

Doubletake

I downloaded the doubletake software, and unzipped the following directory /setup/dt/x64 folder and placed it in a S3 bucket. If you have 32-bit servers extract also the 32bit folder. The below examples only use the 64bit installer… if the need arises we can create also the 32bit playbook.

Make sure the files are public else you will not be able to download it on the source servers, use a the readonly S3 policy attached to a role for the targetservers.

Before uploading also modifie the DTsetup.ini file to allow a quiet installation. (modify it anyway you want, make sure that the diskqueue folder has around 20gb of free space)

 

 

When the above is done, we can continue to write our playbooks.

Write the following playbook, place it in the /etc/ansible directory.

 

 

Then create the following directory structure

/etc/ansible/roles/doubletake/tasks/

The create the following “role”, save it as main.yml

 

Now we can test the doubletake installation like this

Or if you encrypted the files with vault then

 

If everything is working as it should then doubletake should be installed everywhere, nice and fast no?

 

 

Windows Licensing

 

It all depends what you want to do, but this example will change the windows activation to the Aws kms servers, thus using the aws licencing instead of your own or…

Source : “Unable to activate Windows”

Ok that will be a lot of manual work, so let’s not do that.

 

Since ansible is still a work in progress I found that the module win_unzip does not work all the time.

Therefore I chose to put the ec2install.exe also in an S3 bucket.

(wanted to do download the latest ec2config service from amazon and unzip it , then install it…if it works better in the future I’ll make an update)

 

Write the following playbook

 

 

The create the following directory structure

/etc/ansible/roles/windowsactivation/tasks/

Then write the following main.yml and place it in the dir above

 

DNS forwarder

If you have a domain running you probably also have windows dns, because you now going to move to aws, we need to change to forwarder to aws.

!The below script will replace all your forwarders! If you don’t want this then there is also ‘add-dnsserverforwarder’ and ‘Remove-DnsServerForwarder’.

 

So maybe create a group in the ansible host file [activedirectory]

 

To find the ip for the forwarder take your VPC cidr block and change the last digit to 2.

Example: 10.41.0.0/16 the dns forwarder is at 10.41.0.2

source : (VPC Subnets –> subnet sizing)

 

Create the below playbook under /etc/ansible

 

 

Failover

 

Right we have the necessary components now, let do the failover to aws

In the double take console start failing over your servers, best to start with the core servers, like AD, then maybe SQL, exchange.

Then applications servers and webservers… it’s really up to you

 

When everything is failed over, check to see if ansible is able to reach your servers.

(With Kerberos or local user)

Also it can get confusing now because your target servers are also your source servers now! 🙂

 

Anyway, run the setdnsforwarder.yml first to make sure you have internet access.

Then run the windowsactivation.yml

 

Everything should now reboot and come back online, activated with the aws kms server.

Since this is a repeatable process you can first do a testfailover, test this out, tune where needed, then do the actual failover.

 

If you have questions or just don’t want do to this yourself, contact us by email or phone (+32 3 450 80 30).

 

Go Automate Something!

Pauwel

Leave a Reply

Your email address will not be published. Required fields are marked *