Check the VMware Tools custom-script setting and the phase your script expects before rebuilding the template. A Linux guest can have running Tools and receive its normal customisation settings while the optional script is disabled. A script that does run can also fail because it expects networking during a phase in which VMware deliberately disconnects the virtual NIC. Broadcom KB 313048 documents both boundaries.
This is a source-only diagnostic for vSphere 8.0.x Linux guest customisation. No VM was cloned, script executed or configuration changed for this article. The examples below are hypothetical, not observed customer results.
The components involved
The customisation specification supplies the optional script. VMware Tools in the guest handles the customisation workflow, including the deployPkg setting that controls whether custom scripts may run. The guest interpreter then executes the selected script branch. These are different boundaries: healthy Tools alone does not establish that optional scripting is enabled, and an enabled script does not establish that its own dependencies are available.
The KB requires VMware Tools functionality version 10.1.0 or later. That is a feature minimum, not a current support recommendation. Record the actual open-vm-tools package, Linux release, vCenter and ESXi builds, and the specification used for this particular deployment. Confirm the guest combination through the applicable support documentation before planning a change.
Inspect the gate without enabling it
With approved read access inside the affected guest, the vendor-documented query is:
vmware-toolbox-cmd config get deployPkg enable-custom-scripts
This reads configuration; it does not enable scripting or rerun customisation. The syntax has been checked against the KB, but not against installed help or a running system. Check your package's help and access requirements before use. Record the full result and any error privately.
A result showing the option disabled explains why a script is not permitted to run. An enabled result only removes that particular explanation. A missing executable, access failure or unrecognised option is inconclusive: establish the package and version rather than treating an error as a false value. The KB states that this option is disabled by default for security. Enabling it permits code execution through this workflow and belongs in a separately reviewed template change.
Next compare the script stored in the selected specification with the intended revision. Inspect its first argument handling without executing it. The documented argument names are precustomization and postcustomization; a branch expecting a different string will not select the intended work. A newer script in a source repository is irrelevant if the deployment selected an older specification.
KB 313048 also warns that an error in the script can fail customisation itself. A pre-phase error followed by failed customisation is a different outcome from the headline case where the IP settings were applied but an optional script did not run. The article focuses on 8.0.x; the 7.x size limit below is a labelled comparison, not an independently verified 7.x procedure.
Choose the correct phase
For precustomization, VMware calls the script before guest customisation begins. The virtual NIC is disconnected, so network access is unavailable. The source states that the default 100-second customisation timeout includes time spent running this phase. A long remote-download retry loop therefore combines an unavailable dependency with a finite budget.
For postcustomization, the script is scheduled in the initialisation process after the VM powers on and customisation finishes. The NIC is connected. That permits network access; it does not demonstrate that a DNS answer, route, remote repository or application endpoint is ready. Do not extend the documented pre-phase timeout into an unsupported claim about every post-phase execution.
The KB also distinguishes script-size limits: 1,500 characters in vSphere 7.x and 65,536 in 8.x. If a specification is moved between releases, inspect that boundary as well. A larger permitted script is not evidence that its interpreter or dependencies are compatible.
Worked diagnosis
Suppose a hypothetical Linux clone has its intended address but no application bootstrap marker. The specification's script tries to download a package in its precustomization branch. The configuration query shows scripting enabled.
The enabled gate does not explain the missing marker. The branch's network dependency does: that phase has no connected NIC. The technical correction to evaluate is a phase-appropriate design, such as keeping only local preparation in the pre-phase and placing network-dependent work in a reviewed post-phase workflow with explicit readiness handling. Raising a timeout cannot create a network connection that the phase deliberately lacks.
If the query instead reports scripting disabled, resolve that policy decision first with the template owner. Changing branch timing alone will not overcome the gate. If the gate, branch and phase all agree, inspect existing customisation and script error evidence for the actual failed operation; do not label every missing output a Tools fault.
Acceptance and safe reversal
Inspection is complete when the record ties one VM to its exact specification revision, Tools package, gate value, selected phase and unmet dependency or remaining unknown. That establishes a diagnosis, not a successful deployment. Functional acceptance requires a separately authorised disposable-clone exercise showing the intended branch, completion within its applicable budget and the expected guest result. No such exercise was performed here.
Before an eventual template change, preserve its previous script and gate values. Reverting those choices affects future deployments; it does not undo files, packages or external registrations already created by a script. Never rerun both branches on a production guest merely to collect evidence.
Learning notes
- Running Tools and permission to run a customisation script are separate facts.
- Pre-customisation networking is intentionally unavailable.
- A connected NIC in the post-phase is a prerequisite, not an application-readiness result.