At the moment we are using a vCO Stub to do out Guest Customization.
Most Steps are in Guest Scripts injected by VMware Tools.
Now we checked the Guest Agent Way but there is a big Problem for us. All Provisioned VMs are in another Network than the vCAC IaaS Part…
And some of the actions required in the Guest are only possible in the destination Network e.g. Join an other domain.
At the moment during the provisioning process the VM is directly placed in the destination network.
Has anyone else to solve such a situation?
"At the moment we are using a vCO stub to do out Guest Customization" <- then you are doing it correctly, and sounds successful, why would you want to move away from this in the first place?
"And some of the actions required in the Guest are only possible in the destination Network e.g. Join an other domain." <- Use a vCenter customization specifications in your blueprint.. we use this for sysprep & joining to the domian... vCO for everything else.
I try and avoid the Guest Agent if I can
Agreed here. The guest agent is pretty much totally unnecessary so far as I can tell. At least for vSphere endpoints. Unfortunately there are some pieces of IaaS that only seem to work when it sees the guest agent and I think you'll need it for physical hardware and non vSphere endpoints. I think the one stumbling block you'll hit with a vSphere VM is if you enable disk modifications. Without the guest agent no modifications to the partitions will take place and no file systems created.
We do everything with vRO + Guest Script Manager package. Assuming you are all vSphere and all vm's have the tools installed this works flawlessly (for us).
At the Moment everything works fine with this way.
But I expect that some things like Disk handling are in a more pretty way like a custom vCO Script…