Any new machine in a dedicated pool we have won't finish customizing. I have noticed that the machine names don't change when they are deployed from the template and that there is an odd line 'this machine is not configured by a view connection server' in the view agent logs. Also the view agent never gets detected. Did check that the vm can see the connection server and it can. This problem has been hard to diagnose because after a certain amount of time I get locked out of the machine because the admin account becomes disabled (even though I tell it to enable in the sysprep customization spec file). Since the machine isn't on the domain none of our domain accounts work and I am unable to remotely access c$ since the local admin account is disabled.
Things went really wonky in our environment when our network admins changed all server/admin passwords. Unsure if this is related or not. We did have to enter new credentials inside of view but maybe we missed something? Existing non-dedicated pools are working normal. If I recompose a pool from the snapshot that the template is built from I don't have any issues but I am using quick prep also. Verified the account that the customization spec uses to join to the machine to the domain is working correctly.
So at least in this particular case the windows store being disabled was causing the issue. Which I find odd since we have done this on physical machines without any problems syspreping. Undid all the MAK stuff since we use volume keys and don't really need to worry about rearm counts (we get 999)
Whether the issue observed for both sysprep and quickprep customization ?
Seems to work fine for quick prep. Which leads me to believe it may be an issue copying the sysprep onto the VM. I did see in the view logs on the VMs the sysprep command it was running but didn't think to actually check and make sure the sysprep file was present on the machine.
So I do see that the sysprep file gets copied but I don't believe any of the customizations actually happen. The dates on the sysprep error logs are from when the original machine was built. There is still the issue that that the machine name is the original machine name and not the machine name as specified through view.
[2015-03-03T09:08:56 DEBUG] Moving directory 'sysprep' to 'C:'
[2015-03-03T09:08:57 DEBUG] select * from win32_networkadapter where Manufacturer != 'Microsoft' and ServiceName != 'VMnetAdapter' and manufacturer is not null and MACAddress is not null
[2015-03-03T09:08:58 DEBUG] Found 1 objects. Pointer e4ace0. return code 0(0x0)
[2015-03-03T09:08:58 DEBUG] Found 0 objects. Pointer 0. return code 1(0x1)
[2015-03-03T09:08:58 DEBUG] Returning value 00:50:56:B2:05:78 for system property
[2015-03-03T09:08:58 DEBUG] Setting dhcp for nic # 0
[2015-03-03T09:08:58 DEBUG] Returning value \\VDIMASTER-TEST\ROOT\CIMV2:Win32_NetworkAdapter.DeviceID="0" for system property
[2015-03-03T09:08:58 DEBUG] ASSOCIATORS OF {\\VDIMASTER-TEST\ROOT\CIMV2:Win32_NetworkAdapter.DeviceID="0"} where ResultClass = Win32_NetworkAdapterConfiguration
[2015-03-03T09:08:58 DEBUG] Found 1 objects. Pointer e45180. return code 0(0x0)
[2015-03-03T09:08:58 DEBUG] Found 0 objects. Pointer 0. return code 1(0x1)
[2015-03-03T09:08:58 DEBUG] Clearing gateway ip addresses.
[2015-03-03T09:08:58 DEBUG] Enabling DHCP on the computer
[2015-03-03T09:08:58 DEBUG] Returning value \\VDIMASTER-TEST\ROOT\CIMV2:Win32_NetworkAdapterConfiguration.Index=0 for system property
[2015-03-03T09:08:58 DEBUG] Setting DNS Server to ip
[2015-03-03T09:08:58 DEBUG] Executing command C:\windows\system32\sysprep\sysprep.exe /quiet /generalize /oobe /reboot /unattend:C:\sysprep\sysprep.xml
[2015-03-03T09:08:58 DEBUG] Successfully executed command C:\windows\system32\sysprep\sysprep.exe /quiet /generalize /oobe /reboot /unattend:C:\sysprep\sysprep.xml
[2015-03-03T09:08:58 DEBUG] Trying to connect network interfaces, attempt 1
[2015-03-03T09:08:58 DEBUG] Rpci: Sending request='deployPkg.update.state 4 103 C:\Windows\TEMP\vmware-imc\guestcust.log@4000'
[2015-03-03T09:08:58 DEBUG] Rpci: Sent request='deployPkg.update.state 4 103 C:\Windows\TEMP\vmware-imc\guestcust.log@4000', reply='queryNicsSupported', len=18, status=1
[2015-03-03T09:08:58 DEBUG] Got VMX response 'queryNicsSupported'
[2015-03-03T09:08:58 DEBUG] Rpci: Sending request='deployPkg.update.state 4 104 C:\Windows\TEMP\vmware-imc\guestcust.log@4000'
[2015-03-03T09:08:58 DEBUG] Rpci: Sent request='deployPkg.update.state 4 104 C:\Windows\TEMP\vmware-imc\guestcust.log@4000', reply='disconnected', len=12, status=1
[2015-03-03T09:08:58 DEBUG] Got VMX response 'disconnected'
[2015-03-03T09:08:59 DEBUG] Rpci: Sending request='deployPkg.update.state 4 104 C:\Windows\TEMP\vmware-imc\guestcust.log@4000'
[2015-03-03T09:08:59 DEBUG] Rpci: Sent request='deployPkg.update.state 4 104 C:\Windows\TEMP\vmware-imc\guestcust.log@4000', reply='connected', len=9, status=1
[2015-03-03T09:08:59 DEBUG] Got VMX response 'connected'
[2015-03-03T09:08:59 INFO] The network interfaces are connected on 1 second
[2015-03-03T09:08:59 INFO] GuestCustUtil exiting.
## Starting deploy pkg operation
Deploying C:\Windows\TEMP\vmware-SYSTEM\000007bf\imcF123.tmp
Package command = guestcustutil.exe customize -sealparam "/quiet /generalize /oobe /reboot" -nics 4000 -schedulenativeunobfusc
Running expanded command: C:\Windows\TEMP\vmw9106.tmp\guestcustutil.exe customize -sealparam "/quiet /generalize /oobe /reboot" -nics 4000 -schedulenativeunobfusc
Command completed with exit code 0
Ran DeployPkg_DeployPackageFromFile successfully
## Closing log
edit: So I guess I was looking in the wrong place for the sysprep files, I did find this relevant errors
2015-03-03 09:11:03, Info [0x0f00bd] SYSPRP CreateSysprepActionList: Building action list for component Microsoft-Windows-ErrorReportingCore
2015-03-03 09:11:03, Info [0x0f0080] SYSPRP ActionPlatform::LaunchModule: Found 'WerSysprepGeneralize' in wer.dll; executing it
2015-03-03 09:11:03, Info [0x0f0081] SYSPRP ActionPlatform::LaunchModule: Successfully executed 'WerSysprepGeneralize' from wer.dll without error
2015-03-03 09:11:03, Info [0x0f00bd] SYSPRP CreateSysprepActionList: Building action list for component Microsoft-Windows-Store-Licensing-Client
2015-03-03 09:11:03, Info [0x0f0080] SYSPRP ActionPlatform::LaunchModule: Found 'WSLicenseCleanUpState' in C:\Windows\System32\wsclient.dll; executing it
2015-03-03 09:11:03, Info SYSPRP Entering WSLicenseCleanupState - Client Stub
2015-03-03 09:11:06, Error SYSPRP WSLicenseCleanUpState failed with hr=c0020017
2015-03-03 09:11:06, Info SYSPRP Exiting WSLicenseCleanupState - Client Stub
2015-03-03 09:11:06, Error [0x0f0082] SYSPRP ActionPlatform::LaunchModule: Failure occurred while executing 'WSLicenseCleanUpState' from C:\Windows\System32\wsclient.dll; dwRet = 0xc0020017
This article implies this is a rearm count issue. Has anyone seen this? We normally use quick prep so I guess we might not have encountered this issue until now. Seems like a really stupid way to need to build a template if this is the solution
Windows 7/2008 Deployment - KMS and MAK Keys pt. 3 | Technodrone
So at least in this particular case the windows store being disabled was causing the issue. Which I find odd since we have done this on physical machines without any problems syspreping. Undid all the MAK stuff since we use volume keys and don't really need to worry about rearm counts (we get 999)