I'm experiencing this same error as well.
This issue is networking related, however I'll need access to the agent logs to tell what exactly is going on. Here is what you can do. You can disable provisioning on the pool when you see this error. That should prevent the vm from being deleted/recreated. Login to one of these error vms and collect the log bundle (no dmp required).
Looking at the vmware-viewcomposer-ga-new.log, customization seems to be failing when running nltest.exe /sc_change_pwd with an "ERROR_NO_TRUST_SAM_ACCOUNT". There seems to be some sort of timing issue, as the machines will eventually run customization successfully. Our AD sites are set up correctly, though we do have multiple domain controllers per site. Is there a way to force the device to use a single domain controller?
for me the log "vmware-viewcomposer-ga-new.log" was gvining "no adapter with ipv4 enabled" and also. i followed the installation for the hotfix on the following link and the issue dispappeared.
with best regards
I'm having the same issue here and tried the KB article as Medo060 described however when I tried to install the window hotfix it said it didn't apply to that VM. Anyone else have something else to try?
If the OS is 32bit you have to get the x86 file. if it is 64 bit you have to get the 64bit version.
We found our master image had a ghost NIC after installing the patch. Use the following steps to resolve. Note the the commands need to be exactly as shown, and there are no warnings or errors if typed incorrectly.
1. Run a command prompt as Administrator
2. Run the following commands
3. Click Show hidden devices on the View menu in Device Manager
4. Browse down to Network Devices and remove/uninstall any hidden/extra (grayed out) VMXNet3 NICs
Our issue is not caused by network connectivity, as the patch is already installed and there no old hidden NICs. Also, the issue occurs with Windows 10. Also, our pools will eventually provision correctly after retrying. In our vmware-viewcomposer-ga-new.log, customization seems to be failing when running nltest.exe /sc_change_pwd with an "ERROR_NO_TRUST_SAM_ACCOUNT". There seems to be some sort of timing issue, as the machines will eventually run customization successfully. Our AD sites are set up correctly, though we do have multiple domain controllers per site. Linked clones work fine. Does anyone actually have instant clones working outside of a lab environment? VMware, anything you can add here??
Any news on that?
I am experiencing this as well...
2016-06-01T23:43:26.183-07:00 ERROR (0B24-1B08) <ThreadedActionBase-0> [VmInformation] (b9716c4f-56d6-4e77-8176-5e98da186b17) The VM: /DC/vm/Win7-InstantClone/Win7-IC-02 - encountered an error: Instant Clone agent initialization state error (24): Failed to update the machine group policy (waited 15 seconds)
2016-06-01T23:43:26.184-07:00 DEBUG (0B24-1B08) <ThreadedActionBase-0> [EventLogger] (b9716c4f-56d6-4e77-8176-5e98da186b17) Error_Event:[BROKER_PROVISIONING_NGVC_ERROR_COMPOSER_AGENT_INIT_FAILED] "Provisioning error occurred for Machine Win7-IC-02: Instant Clone agent initialization failed": MachineId=9fbeafaa-5a95-485f-a023-b1185daf9aad, MachineName=Win7-IC-02, Node=cs01.lab.local, Severity=ERROR, Time=Wed Jun 01 23:43:26 PDT 2016, Module=Broker, Source=com.vmware.vdi.desktoptracker.VmInformation, Acknowledged=true
The issue here is the password replication across various ad sites. This problem is being worked upon, and should hopefully be fixed soon. In the interim the workaround is to not reuse the same vm names.This can be achieved by the following steps.
1) Follow this KB to connect to ADAM db on any one of the brokers (https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2012377).
2) Go to OU=Server Groups and double click on the Instant Clone pool name that has they want to test.
3) Scroll down to attribute named pae-VmNameReuseAllowed and change its value to 0.
4) Give it a few minutes and then try out deletion/pushImage operations
Once this is done, the desktop names will keep incrementing. I'll update again once the release vehicle for the fix is identified.
Thanks for your input...I have implemented what you've suggested and the previous error now is replaced with this one below...
Provisioning error occurred for Machine Win7-JiT1: Instant Clone agent initialization failed
Etamir, can you verify that the agent on your parent image is setup for instant clones and not linked clones?
I tried the solution you provided, but we still see the same errors, though they do occur less often. It's frustrating that the instant clone feature is so buggy. Is it meant to just be an "experimental" feature, or does VMware actually think it can be used in a production environment?
The error might still happen if the same vm name is used again. This can happen if the desktop that is being recreated is the highest number'ed one. As an example, if you have [vm-1, vm-2, vm-3] in your pool and vm-3 is the first desktop to be recreated, then the name allocation will choose vm-3 again. On the contrary if either of vm-1 or vm-2 were deleted first then this issue will not happen. As you can see this becomes unlikely for larger sized pools.
We are sorry that you are still seeing this issue, but Instant Clones feature has undergone proper testing cycle. As with any piece of complicated s/w there are bound to be bugs and I would agree that this is a particularly critical one. We would encourage you to contact GSS and register your case. This would help us in releasing the fix for this problem earlier.