Physical to Virtual of RD Server on the same server

Question

I need to Physical to Virtual our Remote Desktop Server (Server 2008 R2), install the HyperV role on the Physical server and then eventually have the converted RD VM back running on the Physical Server.

I have read numerous threads on similar topics where certain people suggest that at least one of these should be a fresh install to avoid any issues down the line with regards to duplicated SID/GUIDs etc, and others suggesting it should be fine if one is SYSPREP’D (the Microsoft SYSPREP documentation also says RD is supported). However, I want to exhaust all avenues before doing a complete reinstallation/rebuild of either the Physical or the VM as there’s a couple of other applications I want to keep running on both and avoid any reinstallation/configuration. I would also like to run the P2V VM on another HyperV host before changing any/or minimum configuration of the current Physical to ensure the VM is fine and all services will work.

In regards to the current Physical server it is the gateway and has the RD licensing manager installed with licenses configured on it along with the remote apps.

I intend to SYSPREP the VM before configuring the Network Adapter. If I want to avoid any changes to the current Physical then I assume I am going to have to change the Server name and IP of the VM and then add/change any internal DNS and firewall rules to point to the new IP temporarily.

The questions however are:

1. Will everything function within the VM including the licensing after the conversion and SYSPREP, or what configuration is going to be required? i.e. will the licenses need setting up again?
2. Is there any additional configuration required for a RD server if the name of the server is changed?

The following is a breakdown of what I was hoping would be successful:

1. P2V the Physical Server using sys internals disk2vhd.
   2. Move the VHD to another HyperV host in our environment.
   3. Configure a new VM on the HyperV host and attach the VM, do not configure Network adapter.
   4. Boot VM and SYSPREP
   5. Configure NIC, assign IP, rename Server
   6. Setup A record for internal DNS and point current inbound RD Firewall rule to new IP of VM.
   7. Once confirmed working, install HyperV Role on Physical server.
   8. Move VM back to the Physical Server.

Is there anything I have overlooked or potential pitfalls?

Thanks in advanced

Answer 1

Take this with a grain of salt as I haven't tried to do something like this in quite some time.

Without knowing more about the "couple of other applications" you "want to keep running on both and avoid any reinstallation/configuration", it's hard to say whether sysprep is going to 'break' them. Some applications support or recover gracefully from a sysprep while others require some massaging; the latter is especially the case for 'GUID-y' applications. But there's no way for us to know because we don't know what those products are. You'd be wise to open a case with Microsoft for guidance on this process as a whole and reach out to the vendor(s) for the application(s) in question.

I'd probably take a path similar to the following:

1. Develop a validation & regression testing document if you don't already have one.
2. Schedule some down time within the organization
3. Take a image of the physical machine (ghost, acronis, macrium, clonezilla, gparted if need be - whatever)
4. P2V 'Physical Machine A' (PM-A) as 'Virtual Machine A' (VM-A)
5. Spin up a VM elsewhere & attach the VHD/X for VM-A created above
6. Configure the newly created VM for VM-A (e.g.: create switch, put it on the proper VLAN etc.)
7. Shutdown PM-A or disconnect the NIC on PM-A
8. Turn on VM-A
9. Test & reconfigure VM-A and other services within the organization accordingly

If VM-A functions as expected and services continue functioning as it did before for your organisation, leave the fully functional server, VM-A, running as-is: Don't change the name or IP address or anything else since it's a "known good" configuration.

Once you've finished performing your validation & regression tests for VM-A, turn your attention to PM-A where you could either: - wipe the slate clean by rebuilding it, OR - sysprep it then reconfigure accordingly

Try the sysprep approach & see how things work when it's all said & done. If it works, great - job done. If not, troubleshoot. If you you've reached the point where the law of diminishing returns applies, rebuild it from scratch & reinstall & reconfigure the applications. If the sky starts falling:

1. Restore PM-A from the image back up you took earlier
2. Turn off VM-A
3. Turn on PM-A
4. Back to square one