need to re-register cloned vm in DNS?

[np123]

I'm cloning Windows 2008R2 and 2012R2 vms in a domain and giving the clone a new name with OS customization. I'm wondering if the need to re-register the source vm (the vm being cloned) in DNS is normal. When the source vm is powered off during cloning, the question is moot because the source vm re-registers itself in DNS at the next boot. (I don't care if it has no DNS record while powered down, because it's obviously inaccessible anyway.) The question is really about cloning running vms.

The Windows System log on the clone suggests that the name change is a two-step process:

a - 10:30:34 "The NetBIOS name and DNS host name of this machine have been changed from SOURCEVM to WIN-PBDJASQHPHD."

b - 10:30:52 "The NetBIOS name and DNS host name of this machine have been changed from WIN-PBDJASQHPHD to PROVSNTEST1."

The vm NIC is disconnected for some of the customization process. If the clone's vm NIC were disconnected for step 'a' (above) then presumably re-registering the source vm in DNS afterwards would be unnecessary when cloning a running vm? In my case (ESXi 5.5.0, 1892794, VC 5.5.0, 2646482) the clone's vm NIC seems to be connected during step 'a'. So I wonder if that's by design. Of course the clone's vm NIC must be connected to join a domain, but at least in theory, the change to the temporary name could happen with the NIC disconnected, so the source vm's DNS record is not purged.

If other folks are cloning running vms in a domain, do your source VMs drop out of DNS? If it's normal, maybe we'll need to anticipate downtime for vms that need cloning.

Possibly related Cloning a vm gets wrong dns entry

[LucD]

Is the OS using as volume licensed key or a retail key ?

With the 2nd type of key, the OS will go through activation, and it could be that the sysprep network customisation is not completed.

It would be handy to have a look at the sysprep log (see KB2001932)

[np123]

The OS is using a volume licensed (MAK) key. Sysprep seems to have completed successfully: setuperr.log is empty, console was logged in as the administrator, and customization changes were all in place.

[np123]

In other words, sysprep seems to have succeeded, but the DNS record for the hot-cloned vm is nevertheless purged. I could use Invoke-VMScript to re-register the source vm, but I don't want to go there unless the purged DNS record is expected. Is it expected? Or has anyone found a cleaner solution?

[LucD]

Just a thought, can't put you place the cloned VM in an isolated VLAN, till sysprep completes ?

That would avoid purging the DNS record, I think.

[np123]

Thanks. Of course sysprep can't join the domain from an isolated VLAN, unless I've misunderstood the suggestion. But yes, the customization spec could specify a workgroup with the clone's nic disconnected or isolated in a VLAN. That way sysprep renames the source vm but does not attempt to join the domain. Then I'd reconnect or move the clone's nic and join the domain (manually or with Invoke-VMScript) as a separate step, outside the VMware cloning process and its OS customization routine. Any idea if hot cloning in a domain is generally done this or some other way? Or generally not done?

Some backstory in case this seems like a silly question... In the past I cloned several running VMs without noticing DNS dropouts. So I assumed that the clone's first name change, from the source vm's name to the temporary name, happens while the nic is disconnected. Noticing the DNS dropouts recently, I wondered if some buggy recent version or patch was connecting the clone's nic too early, making that first name change too late, or otherwise causing the dropouts. But that might be wishful thinking; it's also possible that in the past we simply never noticed the problem.