AWS – EC2 Upgrade Solution
Ever wonder what it would take to upgrade your AWS EC2 instance from Windows 2012 Standard to maybe Windows 2016? First you do the normal and make sure Microsoft supports the in place upgrade that you desire.
We put together a test environment just to see what we would be getting into. First we downloaded the AWS inplace upgrade instruction sheet. The vernacular of that sheet, was truly dizzying due to it’s breadth. Some of the information required was only found in the document, so it becomes a must read. In this test, we will copy the servers from a production AWS account to a test AWS account to make sure we do no harm to the production servers.
Moving the servers to test AWS account
Step one, make sure everything is backed up. We use two methods on AWS servers to get them backed up. Method one “Cloud Ranger” which allows you to backup 10 servers for free. Once your on the 11th a monthly fee is required. The data is stored on a snapshot in your S3 account. With each backup we create an AMI. The AMI is key to making the server copy. The second backup is our online backup software which does a backup every 15 minutes. This ensures we have any data loss between the “Cloud Ranger” backups covered to within 15 minutes.
For this step we backup using cloud ranger and back up to an AMI. You can also create an AMI in the Amazon console which we will do for the return trip. Once your AMI is created, it needs to be shared.
To share the AMI go to your production console and go to EC2 then AMI- Actions, Modify Image Permissions. Add the AWS ID number of your test account then check the box “add create volumes”.
Write down Instance ID and availability zone for each server being upgraded along with all IP settings, internal to the server, external on the AWS NIC(s) and elastic IP’s. If your doing a real upgrade, leave the server up, but shutdown the web service, or other services that may cause data change during the upgrade, make the server is accessible to no one but you. Leave it turned up to make it easier to get back up if your upgrade fails.
On the test AWS account EC2 Console -> Images -> AMI then in the bar on the top with the titles, there is a filter selector on the left. Choose Private images. Your AMI’s from the other account should be there. Launch each AMI one at a time. Take an instance size at least as large as the production server.
We found when they come up, we often have to add a second NIC as the first NIC is stuck with the old account settings.This is indicated by 1/2 status check on the instance, if this happens, add second NIC, add an elastic IP address to new NIC, reboot, stop/start. We add an elastic IP, so we have control of the IP. Then you have to modify the security group to you can access the server from your location once it boots.
Re-Boot the moved server
From the AWS console verify the server is started. Make sure the checks all show completed and good. Under actions select instance and view screen to verify the server is up. Now use the elastic IP to see if you can get on the server using RDP. We use other desktop apps similar to Team Viewer that can make this easier when we do this, but RDP work most of the time. If anything is not right, especially a failed check, restart the server. After we mess around with adding a NIC and IP, it may take a couple reboots to wake up the server. This part is painful, but one just has to mess with it, and it will work.
Begin the Upgrade
Assuming your server is up, and you are logged in go to the nic setting and make IP 6, and IP4 DHCP. We have had a 100% failure rate on upgrades if these are hard set to a non existent network.
- Uninstall Ec2Config
- Install EC2 Launch – Full use instructions
- Install SSM Agent
- Create a new volume from a Windows Server installation media snapshot.
- In the navigation pane, choose Snapshots, Public Snapshots.
- Add the Owner filter and choose Amazon images.
- Add the Description filter and enter Windows 2016 English Installation Media . Press Enter.
- Select the snapshot that matches the system architecture and language preference you are upgrading
- Choose Actions, Create Volume
- In the Create Volume dialog box, choose the Availability Zone that matches your Windows instance, and choose Create. May have to leave and come back for it to enter correct device info
- In the Volume Successfully Created message, choose the volume that you just created
- Choose Actions, Attach Volume
- In the Attach Volume dialog box, enter the instance ID and choose Attach. May have to leave and come back for it to enter correct device info.
- Turn off AV, Firewall and non essential services
- On Server, verify new drive had been created, and what letter
- In powershell, change to that drive letter, Type ./setup.exe /auto upgrade if 2016 or 2019, if 2012 Sources/setup.exe
- It will take a while, then choose Desktop 20XX, start install
- We are seeing about an hour for the install
- Log in once the upgrade is done. (Note-We have seen a high rate of servers fail at 31% viewed through the AWS console EC2 Instances screen view tool if yours fails try to update only one upgrade higher 2012 Standard to 2012 Standard R2, then 2016), The upgrade process can be trying. Again it’s doable, just convoluted.
- Once logged in, Install Ec2Config once again.
- Run all the Microsoft updates, if they are going to fail, this is a good time for them to do it.
- Test your server makes sure everything is still working.
Move the Server to Production
- Shutdown Live Server
- Make sure your elastic ip is preserved. To preserve an Elastic IP, disassociated the IP address, but don’t release it until the server is up and running in production.
- Go to the test AWS account, go to EC2 then AMI right click on the AMI. Choose modify image permissions. Enter the Account number of your production AWS Account. Check the box to create the volumes. It will take about 10 minutes to make this package.
- Terminate the production instance (Make sure your backups are still around)
- Go to the production AWS account, EC2, AMI, then look through the private AMI’s for the one you just sent from the last step.
- Use the same launch process you used when you moved the AMI to the test environment.
- If you want the private IP address of your old server, you enter it during the launch wizard.
- Use all the information you copied down for availability zone, and networking parameters.
- Test all your applications in production.
AWS – EC2 upgrades are not a walk in the park. Some servers would be more easily built fresh and reloaded. If your server has a lot of complex custom code and applications an in place upgrade may be your best choice. These steps are long, and are assuming basic EC2 knowledge. The benefit of upgrading in separate AWS account is if your upgrade fails, you have only lost a copy of your server, not your server. In testing, we have found the whole process miserable, so upgrade only if you must. In the end if you have a private IP schema you are trying to maintain. Run the upgrade in the test environment, and if it goes well, you can run the upgrade in place on the production servers. If you made the AMI, transferred them and verified them on the test account you know your route back is clear. In the end, this is what we found to be most effective. AWS network configuration on an imported server while the other one exists will not work, the old server retains the nic config, and if your IP’s are on the primary nic, you only terminate the production instance before moving forward.
We make no promises as to their perfection, and make no guarantees to stability, and data integrity. Please test all of these steps is a scratch environment before attempting this in a production environment. A simple server upgrade start to finish should take about 2 hours to upgrade in this manor. Some servers will take longer depending on instance type. If this upgrade is something you would rather have done by Small Biz PC. Contact us and we will do what needs to be done.