During the instant clone pool creation, a temporary full clone of the golden image known as the “internal template” (with a device name itXXXXXX) powers on and has network access. The sensor on that internal template device will probably connect to the Carbon Black Cloud with the same Device ID as the golden image. This connection results in the golden image being overwritten by the itXXXXXX device in the Carbon Black Cloud console.

Note: This issue is resolved with the Carbon Black Cloud Windows sensor 3.7MR2.

When the golden image is powered on, the sensor on the golden image re-connects to the backend and overwrites the itXXXXXX device. In addition to the duplicate devices overwriting each other’s data on the backend, this can lead to the backend sending a re-register request to the golden image. This causes the golden image to be considered a VDI by the backend, which could cause the golden image to deregister due to inactivity.

The duplicate device scenario can also expose a group membership issue where the golden image is no longer in the expected policy group. The negative implications of the internal template having the duplicate device ID as the golden image are as follows:

  • The internal template’s events and activities can intermingle with the golden images.
  • The golden image’s device name in the console might change.
  • If you are using MSM to assign device policy by device name, make sure that golden image and internal template names are accounted for.

We recommend that you deploy instant clones with the golden image powered off. This recommendation will not eliminate the internal template duplicate Device ID scenario, but it will mitigate the downside of having a duplicate Device ID.

Provisioning of instant clones with the setting Provision all machines up front can cause a measurable increase in CPU utilization on the hosts and the provisioning clones during the initial provisioning operation. This is a result of the Carbon Black sensor registration occurring on all the provisioning instant clone at the same time.

Provisioning of instant clones with the setting Provision machines on demand is unlikely to cause an increase in CPU utilization because the instant clones are provisioned at different times.

As a result of higher CPU load, during initial instant clone provisioning the customization might time-out for the clones while executing the post-synchronization batch file. This can cause an error state for the clones. The error state is due to the 20 seconds timeout limit for executing the post synchronization scripts on the clones, but the failed clones will auto-recover. The 20 seconds default timeout of the Post Synchronization script can be adjusted by modifying the following registry key in the golden image. This reduces the instant clones provisioning failure rate. The maximum suggested value is 120000ms.

HKLM\System\CCS\Services\vmware-viewcomposer-ga
Type: DWORD
Value Name: ExecScriptTimeout
Units: milliseconds
Sample:
##Updated timeout value from 20000 to 120000 .
HKLM\System\CCS\Services\vmware-viewcomposer-ga
Type: DWORD
Value Name: ExecScriptTimeout
Units: 120000