Migrating Microsoft Windows Server 2003 / 2008 to Amazon EC2
This article will guide you through migrating legacy Windows Server workloads to AWS EC2, providing solutions for any issues you may encounter along the way.
Introduction
Migrating legacy Windows Server 2003 and 2008 systems can be a daunting task, especially given their end-of-support status. However, moving these critical workloads to the cloud can significantly enhance their performance, security, and scalability. In this blog post, we will guide you through the process of migrating Microsoft Windows Server 2003 and 2008 to AWS using AWS Application Migration Service (MGN). This service simplifies, expedites, and automates the migration of on-premises applications to AWS, ensuring minimal disruption to your business operations. Whether you're looking to extend the lifecycle of your legacy systems or leverage AWS’s robust cloud infrastructure, this step-by-step guide will provide you with the insights and tools necessary to execute a seamless migration.
You might have tried to migrate a Window Server 2003/2008 server to EC2 and it is showing in the AWS EC2 console as running, but it has only passed 1 of 2 status checks. This is the article for you!!!
To make things nice and easy I am using the Agentless AWS MGN vCenter Client. This article is not about how to use AWS MGN, please refer to my previous post here to learn how to use AWS MGN to migrate VMware workloads to AWS.
In this article I used a Windows Server 2003 Virtual Machine.
The process of updating the required settings and installing the required drivers (excluding the migration time) was about 15 minutes, so this is extremely quick and easy to get up and running.
Prerequisites for Migrating Windows Server 2003 and 2008 with AWS MGN
- Non-Nitro based Instances (XEN Hypervisor) see a list here - https://docs.aws.amazon.com/ec2/latest/instancetypes/pg.html
- I tested using t2.medium and m3.medium instances
- 2003/2008 does not have the the drivers for NVMe and Elastic Network Adapter (ENA), which are in the AWS Nitro AWS Nitro based instances.
The following End of Life Windows operating systems are supported:
- Microsoft Windows Server 2012 R2 64-bit
- Microsoft Windows Server 2012 64-bit
- Microsoft Windows Server 2008 R2 64-bit (patched)
- Microsoft Windows Server 2008 64-bit
- Microsoft Windows Server 2008 32-bit
- Microsoft Windows Server 2003 R2 64-bit
- Microsoft Windows Server 2003 R2 32-bit
- Microsoft Windows Server 2003 64-bit
- Microsoft Windows Server 2003 32-bit
For Windows Server 2003:
- .NET Framework version 3.5 must be installed
- PowerShell 2.0 must be installed
- In my test environment I had all the latest updates patched to my Windows Server 2003 / 2008 Virtual Machines (you must have at least SP2 installed)
For Windows Server 2008 Operating System Versions Supported:
- .NET Framework version 3.5 must be installed for all versions
- .NET Framework version 4.5 or above must be installed for Microsoft Windows Server 2008 R2 and above
- PowerShell 2.0 must be installed
Additional Considerations: Ensure at least 2 GB of free disk space is available to launch a test or cutover instance successfully. The Nitro instance family can only be used with Windows Server 2008 R2 and upwards. Earlier versions are not supported. These prerequisites ensure that the legacy Windows servers are prepared for migration, enabling a smooth transition to the AWS cloud environment.
Other Prerequisites
- Deploy a new (or use an existing) Windows Server (can be any year, I used 2016) into the same VPC and Subnet as the Windows Server 2003/2008 you plan to migrate. This will be used to make changes to the registry on your Windows Server 2003/2008 instance.
- Download and uncompress the Citrix-Win_PV.zip drivers from here into your Windows Server you deployed above
- Take a snapshot / backup of your Windows Server 2003 / 2008 before you do anything else
Migrating Windows Server 2003 / 2008
The first thing you need to do is configure AWS MGN by following my guide here. Also if you are not going to use AWS MGN to do the migration, the following will still help you with your migration.
Before you do the migration, the only setting on the Windows Server 2003 or 2008 we need to change is in Internet Explorer.
- Open Internet Explorer
- Click on Tools in the menu, and select Internet Options
- Select the Security Tab
- Select Local Intranet
For a blast from the past see below; it brings back memories:
- Select Custom Level
- Scroll down to "Launching applications and unsafe files" Select Enable - Note: To install the right network drivers, this requires an exe file to run when we migrate the server and boot it in EC2. Once you have migrated the server you can change this back to the original selection (Disable or Prompt, Prompt is the default)
Ok, you can start your initial replication, using what ever migration tool you decide on. Once again, I used AWS MGN, which makes life super simple for the migration of the virtual machines to EC2 instances. Once the replication has completed, we want to do some testing before we cut over, with AWS MGN you can launch a test instance, so go ahead and do this now. Once again if you are using AWS MGN and are not sure how to do this, follow my guide here.
If you are not using AWS MGN, please create a test instance. Do not cut over your virtual machine yet; it should still be up and running in your environment.
Once your Test Instance is launched, give it a few minutes to start up, and if it shows in the EC2 console, you should try to RDP to your server (make sure you have setup the right security groups and any Elastic IPs if required.
I found that with most of my testing that the instance would start and show running but it would only pass 1 of the two status checks and I couldn't RDP to it, this is why I made this guide.
To check what your instance is doing, you can select your instance from the AWS EC2 console, and selection Actions, Monitor and troubleshoot, Get instance screenshot.
I found a couple of scenarios happened during testing
- Instance was looping thorough the Windows 2003 splash screen - this was generally caused by using an AWS Nitro based instance, instead of a non-Nitro Based instances, Windows 2003/2008 does not have the driver for NVME and Elastic Network Adapter (ENA) which are in the AWS Nitro based instances.
- Sitting in the Windows Login Screen, but not able to login. This is once again the reason I wrote this article, and might be where you are stuck.
So you can see that the login screen is there on the instance screenshot, but you can't login, let's fix that.
Deploying the right drivers for the Windows Server 2003/2008 Instances.
Detach Boot Volume and Attach to your Prerequisites Windows Server instance
If you have not created another Windows Server instance (use Windows Server 2016 to Window Server 2022) go back to the Prerequisites and follow the instructions there.
- Stop your test Windows Server 2003/2008 instance (don't terminate it)
- Once the instance state shows "Stopped" in the AWS EC2 console, click on the instance
- From the tabs, select Storage
- This will show all your EBS volumes for each of the drives in your instance.
- The device name /dev/sda1 is your boot volume (c: drive)
- Copy the volume ID into your notepad or somewhere
- Click the Volume ID, this will take your to the ECS Volumes console
- Select the Volume again (there should only be one in the list, if there isn't find your Volume ID and select the check box)
- Select Action drop down menu and select Detach volume
- This should detach within 30 seconds, press the refresh arrow, next to the Action menu
- Select the Volume ID check box again, and select the Action drop down menu, select Attach Volume
- Select the Windows instance that you created as part of the Prerequisites, this can be any version of Windows, I used a Windows 2016 and Windows 2022 instance in testing
- Select the device name it should start with xvd , you don't want to choose /dev/sda1 as that is the boot volume for your exisiting Windows instance
- Select Attach Volume
- You have now connected your boot drive to your new Windows Instance
Copy Drivers
- Login to the instance you created
- Open Explorer to see if you can see the newly attached drive
- Most likely you won't, so open Computer Management
- Under Storage select, Disk Management
- You should see the new disk listed here, right click on it and select Online
- Open File Explorer again, you should see the new drive
- Select the new drive, you should see the contents of your Windows Server 2003/2008 boot drive
- Create a new folder called citrix, and extract the Citrix-Win_PV.zip drivers here the directory strcuture should be D:\citrix\Citrix-Win_PV (or what ever drive letter you gave to your attached volume
- The file structure should look like this:
D:\citrix\Citrix-Win_PV\Citrix_xensetup.exe
D:\citrix\Citrix-Win_PV\Purge.ps1
D:\citrix\Citrix-Win_PV\PVRedhatToCitrixUpgrade.ps1
D:\citrix\Citrix-Win_PV\Readme.txt
D:\citrix\Citrix-Win_PV\RemoveResidueRedhat.ps1
D:\citrix\Citrix-Win_PV\Upgrade.bat
D:\citrix\Citrix-Win_PV\XenGuestAgent.exe
Edit the Registry
There is a few things that we need to change in the Registry:
- Purge any old drivers that may have been loaded during the conversion process
- Auto install the required Citrix Paravirtual Drivers
- Disable Windows Asking for a Shutdown / Reset reason
- Allow .exe files to run without a prompt confirming we want to run them
All the above changes can be reversed post migration. The reason we need these changes is we need Windows to automatically install the required drivers without any manual input from us, as we don't have remote access to the server.
- In your instance, select the start and either search or run button and type regedit
- Select HKEY_Local_Machine and Select File, Load Hive
- Select the attached volume drive (in my case D:) and navigate to D:\Windows\System32\Config
- Select the file name Software
- Name the hive as 00Software
Part 1 - Purge RH Drivers
- In the Registry go to HKEY_LOCAL_MACHINE\00Software\Microsoft\Windows\CurrentVersion\RunOnce
- Right-click in the right-hand panel and select New, String Value
- Name the value "RHPurge" click enter
- Double click the name RHPurge and in the Value data enter "C:\Windows\System32\WindowsPowershell\v1.0\powershell.exe -File C:\citrix\Citrix-Win_PV\Purge.ps1". Do not include the double quotes
- Press Ok
Part 2 - Install Citrix Paravirtual Drivers
- Right-click in the right-hand panel again and select New, String Value
- Name the String "CitrixInstall"
- Double click the name CitrixInstall and in the Value data enter "C:\citrix\Citrix-Win_PV\Citrix_Xensetup.exe /S" Do not include the double quotes
- Press Ok
Part 3 - Auto Login to Windows
- Now go to HKEY_LOCAL_MACHINE\00Software\Microsoft\WindowsNT\CurrentVersion\Winlogon
- Right-click in the right-hand panel, and select New, String Value
- Name the value "AutoAdminLogon" click enter
- Double click the name AutoAdminLogon and in the Value data enter 1
- Click Ok
Part 4 - Auto Login to Windows Default Username
- Right-click in the right-hand panel, and select New, String Value
- Name the value "DefaultUsername" click enter (if this already exists, skip to step 24)
- Double click the name DefaultUsername and in the Value data enter Administrator
- Click Ok
Part 5 - Auto Login to Windows Default Password
- Right-click in the right-hand panel, and select New, String Value
- Name the value "DefaultPassword" click enter
- Double click the name DefaultPassword and in the Value data enter the admin password
- Click Ok Note: This is going to store the password in plain text, as soon as the server is confirmed up and running go back in and remove this entry from the registry, which you we be able to do from the Windows 2003/2008 registry
Part 6 -Disable Shutdown or Restart Reason Prompt
- Now go to HKEY_LOCAL_MACHINE\00Software\Policies\Microsoft\Windows NT
- If there isn't another Folder (Key) called Reliability, right click Windows NT and select New, Key and name it Reliability. If it already exists go to this folder
- Right-click in the right-hand panel and select New, DWORD (32-bit) Value
- Name the new value ShutDownReasonOn and press enter
- Double click the name ShutDownReasonOn and set its value to 0
Part 7 -Disable Prompt to run exe files
- Now go to HKEY_LOCAL_MACHINE\00Software\Microsoft\Windows\CurrentVersion\Policies
- If there isn't another Folder (Key) called Associations, right click Polices and select New, Key and name it Associations. If it already exists go to this folder
- Right-click in the right-hand panel and select New, String Value
- Name the new value LowRiskFileTypes and press enter
- Double click the name LowRiskFileTypes and set its Value Data to exe;
Part 8 -Save the Hive and shutdown your Instance
- Go to the top of the Registry and select "00Software", select File and Unload Hive
- Click Yes to confirm
- Logout and shutdown the instance
- Check in the AWS EC2 console and make sure the instance is in the stopped state
Re-Attach the Volume
- In the AWS EC2 Console, select the instance you just shutdown
- Select the Storage tab, and click the Volume that was originally your Boot Volume for your Windows 2003/2008 instance
- Select the checkbox on the Volume and select the Actions menu drop down, select Detach Volume
- Give this 30 seconds to Detach
- Once it has Detached, Select the Volume and select the Actions menu and Select Attach Volume
- Select your Windows Server 2003/2008 instance, which is still powered off
- Select the Device name /dev/sda1
- Select Attach Volume
Start the Windows Server 2003/2008 Instance
1.In the EC2 Console, select the Windows 2003/2008 Instance and select the Instance state menu drop down 2. Select Start Instance 3. You can track the process by refreshing the Instance Screenshot view (under Actions Menu / Monitor and troubleshoot / Instance screenshot)
When the instance starts it might take up to 5 minutes to get into the first Windows login (mine took about 2-3 minutes). It will then auto login to Windows and start the deployment of the Citrix PV drivers, if you are following the screenshots you might see a popup saying new hardware has been detected and will look like it is waiting for your input, don't worry you don't need to do anything. After a few minutes you should see the auto install kicking off, this will reboot your instance.
Once the instance has rebooted for the 2nd time, it should goto the Windows Login screen. Now in the EC2 console you should see the Instance state running and after a few minutes it should show pass for both status checks. If you have setup the Security Groups and if required Elastic IPs you can now RDP to your instance.
Clean Up
Once you have logged into your instance, and done some basic testing, you can go into the Registry Editor (regedit) and remove all the additions we made above.
Conclusion
That's it; you should be up and running. This was just your test instance, so make sure you document all the changes and any other details.
Hopefully this was helpful. If you have any comments, feedback, or have found other issues, please comment below and I will do my best to update this post.
Relevant content
- asked 5 years agolg...
- asked 9 months agolg...
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated a year ago