* 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.