Personally I find the optimisation tool heavy handed, particulary when having to deploy VDI to a large complex environment.
You might want to try not disabling so many windows services. I've had problems with the IPHelper service being disabled for instance.
Microsoft have thier own recommended settings for Windows 10 VDI's which improve performance, the UI, switch off all of the telemetry sending services and generally make the VDI less consumer and more enterprise ready. Using GPO's enforces and maintains the settings too.
All of the optimisation templates just come with a disclaimer stating that changes might break your VDI, which they have. :-)
Thank you for the tip.
I will have take a look at your link and try it this way.
About your last sentence I agree and I know that disclaimer, but I could hardly believe that the OS optimization tool (default template) get things not working.
It have been working for 3/4 months, within the environment almost nothing changed. The things that changed were reverted back to the level when it worked (i.e. Microsoft patches).
No problem, hope it helps you out.
The tool itself and default templates update regularly. Had you obtained a more recent version maybe?
Are you able to logon to the cp-template machine when the customisation is supposed to be occuring? If AD\DNS are all good you should have no issues there. I've had the "trust relationship" error in the past as the computer object was created on a DC that wasn't handling that logon session resulting in the "giving up" message.
Checking the composer log at c:\windows\temp\vmware\ may provide more clues.
Have used the b1094 (built-in Windows 10 Template) and the newest b1096 (built-in Windows 10 Template and also tried the LoginVSI one).
In the cp-template we can logon with a local account, but is not added to the domain. The it%number% (which is the computername of the cp-template) is added to the domain.
We don't have a composer server, because we use instant clones so logging can only be done from vCenter or Connection Server.
Surpise - the composer log does get written to during instant clone prep. I don't use composer server either.
Probably we found the root cause. After a vCenter Server Appliance reset, provisioning didn't hang anymore at the cp-template step.
Stupid we didn't tried it earlier...
Sorry for the late response.
We tried a lot of things made a combination of the Microsof's Best Practices, the OS Optimization Tool and experiences from my colleagues. Even that didn't work.
After a reboot of the VCSA somehow provisioning didn't hang anymore.
Thanks for pointing me in some direction. I was almost out of my options.
Great to hear it's working. A reboot. I'll move that to the top of my own troubleshooting list.
How is a reboot Root Cause ??? That is not an answer to the problem....
Its not, I've found this is usually related to something wrong with the computer object, or not releasing the ip before sealing the parent image.