The weather is nice, sun is shining, Saint Patrick is around the corner as someone reminded me today (gonna have to work while they drink a Guinness). Project is going fine and all of a sudden BOOM there it goes, all desktops stuck in customization errors.
I’ve seen this before and mostly it’s one or two desktops that have an issue, here we had 50 out of 50 having an issue. In this blog I’ll show you the cause of this customization error.
First a little info on the environment.
It’s VMware Horizon View 6.01 environment running on vSphere 5.5.
The OS of the servers is Microsoft Windows 2012R2 and the desktop OS is Microsoft Windows 7 x86. We’re using RES Workspace Manager for UEM and Wyse P25’s to connect users to a desktop.
The vm’s land on a local SSD (not my choice) with no smart techniques to manage IOPS.
Nothing really fancy going on, just a nice clean setup.
Deploying a desktop pool goes fine, copying the replica takes some time but that’s because the parent vm is stored on a slow old storage system. After the pool is deployed and we try to change anything things go bad.
When we recompose the pool we notice that the desktops is provisioned and reconfigured a couple of times suddenly it comes to a halt. It stays in that state for over 40 minutes doing absolutely nothing.
40 minutes????? that’s like forever in my time, 40 minutes is killing in a production environment. recomposing the pool takes over 2 hours here for it waits 40 minutes on several occasions.
Suddenly after having rested a while the vm’s time out and jump into error state. VMware recognizes this and starts a repair. quickly the vm’s are brought to life and become available.
Without a Guinness life isn’t as much fun as with a few of them, but we head on and take a look at the logs. VMware has an easy way of retrieving logs both on the connection servers and the virtual machine.
The command to collect the logs from a remote machine is:
vdmadmin -A -getDCT -outfile file_name.zip -d pool_name -m virtual_machine_name
Pool_name is this is the Pool ID, there is no pool name.
The rest is pretty straight forward, it will create a zip file with a vast amount of logging from the agent.
The best logs are stored under Diagnostics of course. VMware will ask for all these files (the logs) once you create a call.
At the connection server from the start menu you can set the debug logging level, set it to Full or debug to get the best result. Next you start the Create debug logging and a folder is created.
Together with both log directories you should be able to find the reason for the issues.
I took a look in the NwtSetup.log and couldn’t find anything, the machine name is set, the desktop is activated and all seems to go fine. Why is the desktop stuck in customization?
Then I found the NGA log file and the error was found. The log reports over and over that it can’t find a volume. VMware clones have a 20MB disk that holds the desktops private parts, it’s identity so to say.
I triggered something here, for they did a trial once with Unidesk and this felt the same. What VMware does is add a VMDK to the virtual machine on the fly. So what I hear you think but if that on-the-fly is not allowed you might see this behavior with systems that do. Unidesk had an issue also here because of a security setting.
There is a policy active on the OU where all the desktops and the template is stored and the policy prohibits adding a VMDK on the fly.
It’s in Dutch but it disallows the addition of certain apparatus ID’s.. need I say more.
So now we have excluded the policy for the VDI desktops and will start a new test.
After disabling the policy, the composing action takes 15 minutes, project back on track!
Other issues that might result in customization errors
There are other reasons why customization errors might occur, DHCP scopes close to being depleted, DNS issues, timeout on scripts, VMXNET3 NIC having issues with VMware.
We checked all these and didn’t find what we were looking for. This sounds like a very good and reasonable solution.