VMware Horizon Community
trakeen
Contributor
Contributor
Jump to solution

new machines in dedicated pool stuck in customizing stage

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.

0 Kudos
1 Solution

Accepted Solutions
trakeen
Contributor
Contributor
Jump to solution

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)

View solution in original post

0 Kudos
4 Replies
kgsivan
VMware Employee
VMware Employee
Jump to solution

Whether the issue observed for both sysprep and quickprep customization ?

0 Kudos
trakeen
Contributor
Contributor
Jump to solution

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.

0 Kudos
trakeen
Contributor
Contributor
Jump to solution

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

0 Kudos
trakeen
Contributor
Contributor
Jump to solution

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)

0 Kudos