On EC2, detach OS volume, write to a file, then reattach OS volume and boot successfully

Question

Summary of steps that I am attempting:

• Detach OS volume from Windows_Server_A
• Attach volume to Windows_Server_B
• Modify a harmless file
• Detach from B and reattach at /dev/sda1 for Windows_Server_A
• Boot Successfully

This is not working. The attach / disk management online/offline / detach process is causing the volume to NOT boot when it returns to Server_A

---

** Detailed Steps**

• Detach OS volume from EC2 windows 2012 instance. Let this be Volume_X
• Attach Volume_X to a temporary EC2 windows instance
• In Disk Management of temporary EC2 server, turn new volume online
• Note that there are two partitions. One small one (350MB) without a drive letter and one large one (100GB). The large one gets a drive letter assigned: G
• Navigate to a particular file on G drive
• Modify the file
• Close all windows
• Turn drive offline in Disk Management
• Shut down temporary EC2 server
• Detach Volume_X from temporary server
• Re-Attach Volume_X to its original server at mount point /dev/sda1
• Attempt to boot original server

• The instance never gets past "initialized" and going to Instance Settings - Get Screenshot yields the following:

  

---

To isolate the problem, I tried without modifying a file:

• With a fresh, working copy of Volume_X. Detach from Original server. Attach to alternate server.
• All I did was turn the drive "online" and then 2 seconds later turned it "offline" without modifying any data on the drive.
• Reattaching to the original server yields the same exact problem

Thus, it appears that I am corrupting Volume_X by simply attaching it and turning it "online" (disk management) on a separate server.

---

What is the proper way to move a windows OS volume to another server, for file modification, to then be returned to its original instance and successfully booted from?

Desired steps:

• Stop original server
• Detach volume
• Attach volume to alternate server
• ????? then modify a file then ?????
• Detach volume from alternate server
• Attach volume to original server
• original server should boot fine

Thanks for your time

Answer 1

As best I can tell, the disk management utility on windows server 2016 does something to the boot partitions (the small ~350MB ones). They simply do not function after going "online" via Server_B's disk management and then "offline". They are no longer bootable on Server_A.

Since our goal boils down to:

• Stop Server A
• Move OS volume to Server B as a data volume
• Modify files
• Move OS volume back to Server A and successfully boot

We can accomplish it as follows:

• Stop Server_A. Shutdown naturally if possible.
• Detach volume from Server_A
• Attach volume to Linux Server_B. You can spin up a temporary linux instance very quickly if necessary. Ubuntu Server worked well for me.
• sudo apt-get install ntfs-3g - confirm that the read/write NTFS driver is installed. It is often installed by default now.
• Run fdisk to find the device name for the partition that you are interested in. We are looking for the identifier for the non-boot partition of the operating system volume (the 100GB partition, not the 350MB partition). Mine was /dev/xvdf2.
• sudo mkdir /mnt/ntfs_fix establish a mount point
• sudo mount -t ntfs-3g /dev/xvdf2 /mnt/ntfs_fix mount the partition as a read/write volume
• Proceed to modify your files. Pico is good for editing text files.
• I changed a registry value by navigating to /mnt/ntfs_fix/windows/system32/config and running chntpw -e SYSTEM (to modify a windows system registry value) chntpw reg edit docs
• When you are done making changes, unmount. sudo umount /dev/xvdf2
• Detach volume from Server_B
• Attach volume to Server_A as /dev/sda1 (must be /dev/sda1 for windows ec2 OS volume)
• Start Server_A

Notes

• If a forced stop of the OS volume was necessary at the beginning, Then you will receive an error when trying to mount on the linux server. You can use sudo ntfsfix /dev/xvdf2 to fix the status of the NTFS volume from a "shutdown improperly" state to a "shutdown properly" state. It should then be mountable. Keep in mind that this has the potential to damage your volume, so if you can avoid it by doing a standard shutdown from Server_A, then do it. Otherwise, make sure you have current backups.
• Linux does not read or write from the boot volume (350MB) whereas windows server does something to it. In this way, we are able to modify only the OS-partition of the OS-volume and maintain a bootable volume for when we reattach and boot from Server_A.