Can I Clone a Running Production Server Win2k8 R2 and Produce it as Secondary Production Server

[chaladhi]

Hi all,

My question is: Can I clone a running Production Server based on Windows 2008 R2 and produce this Cloned VM as secondary Windows 2008 R2 Server with just renaming HOST name and joining this Cloned VM into Domain wihout any problems?

I am doibting about SIDs and Other Registry entried made by Original VM; cloned refernce. Please make me understand clear on this. The licensing, installed softwares and PKI components are all carried to this cloned VM; so will that effect anything on the cloned Vm; putting this Cloned VM into production server role?

Cheers!

[Asifsshaikh]

yes, you can clone running virtual machine. but make sure urenamed all the things before making live. i.e. IP/Hostname/SUID etc.etc..

If not then might be ur current server wil also be affect by this.

Regards,

Asif.

[virtualinstall]

You can use the Guest Customization at the end of the clone wizard to prevent problems with cloning the operating system.

[chaladhi]

So, Existing Registry components or other Under the hood applications wont influence my cloned VM right?

I am so much wanted this particular point to be assured.

Cheers! for help

[Cyberfed27]

We have done this many times with Windows 2008R2.

FYI the old way of thinking about GUIDs/SID's being an issue back in the Windows 2000/2003 days doesn't really apply anymore for 2008 and higher.

I dont the specifics but you can google it if you dont believe me.

[MannyR]

* Despite the age of this discussion the search rank is high within the topic. Since the correct answer is very sparse on details, and because I couldn't find good instructions I decided to come back here once figuring it out and fill things out a bit.

Cloning Windows Server VM guests to Coexist with Original VM, in an Active Directory Environment

Considerations

1. Bringing down the source VM is completely unnecessary. That's in step 4 and denoted by [OVERKILL].  It can be skipped, but see below for reasons why you might not want to. [1]
2. Microsoft officially supports cloning in a very limited use case.  This method is unsupported and may also disqualify the original and cloned VMs from receiving ongoing support.[2]
3. You will need a valid license key, knowledge of the licensing mode/count, and the local machine administrator account credentials.
4. The clone will have a new SID, name and IP address (static or dynamic).
5. I'm writing the instructions from memory so there may be mistakes. Hopefully the conceptual verbosity and your sysadmin kung fu can overcome that.
6. Standard warnings: Test on non-production systems if possible.  Completely back up your production system and verify you can restore from that backup as if the original was vaporized.

Details

1. Get the original VM SID and note it for comparison later.
   • PS \> Get-ADComputer -Filter {name -eq '<hostname of source VM>'} -Properties sid | select name, sid
2. In vSphere create a "Customization Specification" to change the SID. (can be done during cloning but separately allows alteration, verification and study prior to use)
   1. Click the home icon and go to Policies and Profiles.
   2. Click Customization Specification Manager in the Navigator pane.
   3. Click the button to add a specification using these guidelines:
      
      1. Properties - OS: Windows , no custom sysprep file.
      2. Registration Information: <your info>
      3. Computer Name: Enter a name in the Clone/Deploy Wizard
      4. Windows License: <enter appropriate, valid license key>, check the "Include Server License ..." box, <set licensing mode/count as appropriate>
         
      5. Administrator Password: <blank>, <unchecked> (Local machine administrator password will also work if the account hasn't been disabled or renamed.)
         
      6. Time Zone: <your time zone>
      7. Run Once: <blank>
      8. Network: <leave at default, don't alter>
         
      9. Workgroup or Domain: WORKGROUP
      10. Operating System Options:  Check the "Generate New Security ID (SID)" box. (*This is the crucial setting.)
          
      11. Ready to complete.  Verify and save. 
3. Start the clone wizard, specify the customization spec created in step 2, and set DO NOT to power up the clone on completion.
4. [OVERKILL] Once cloning is complete, shut down or disable network access to the original VM.
5. Bring up the clone with network disabled (disconnect NIC) and log in to the local machine administrator account.
6. Verify it has a different SID (powershell), new name and is a member of WORKGROUP. Correct any of these if necessary.
   • !!! *** IMPORTANT: IF THE SID DID NOT CHANGE, Shut down the clone.
   • In vSphere, right click the cloned VM, choose "Guest OS" > "Customize Guest OS", apply the spec again.
   • If the SID still doesn't change, something's wrong with the specification or the process of applying it.
     
   • Do not continue if the SID has not changed. [1]
7. Set a different IP address than the original VM, in vSphere connect the NIC, then add the clone to the domain with its new identity.
8. [If you did the OVERKILL step] Bring up the original VM.  Verify all settings and check domain membership.  If anything is wrong, corrected it and leave and rejoin the domain.

The method above was used recently to duplicate a running production VM with Server 2016 hosting MSSQL, IIS and a webapp.  It needed to be cloned to provide a development environment.  Both servers are up, in production, on the domain as member servers with no issues.

References

[1] It isn't necessary to have the original down at all *IF* everything goes perfectly with the customization process.  However, it isn't always obvious when there are issues, such as the new SID not being applied. In that case, the renaming action will associate the original AD computer account with the cloned VM name in AD and the other VM will drop off the domain.  Rejoining the domain will work temporarily but ultimately a dis-join of one of the VMs will reoccur, as well as other very negative effects of having two systems with the same SID.  To eliminate these risks, these instructions have the original remain down for a period while the clone changes are implemented and verified.  The hope is it all happens automatically, rendering this safety step useless.

[2] https://support.microsoft.com/en-us/help/828287/unsupported-sysprep-scenarios.  Note: I believe the resultant VMs don't appear as cloned from the OS standpoint. Some manual work may need to be done from the installed application standpoint.  For instance, in MSSQL I ran commands to change the "local" instance name.  By default, this wasn't necessary for functionality, just prudence.  Form some, losing Microsoft support viability is not a concern as they consider its efficacy and value extremely low.  YMMV.