When deploying VMs with Windows guest operating systems, you may observe that the assigned IP address is not the address you expected, and is instead within the range reserved for Automatic Private IP Addressing (APIPA) 169.x.x.x.


These addresses are not provided to the VM by vCommander®, but instead indicate an issue with the guest operating system obtaining an IP address. This is a default behavior for Windows, and can occur for a variety of reasons, some of which are discussed below.


Template Hardware Configuration

The template or VM upon which the service is based may have one or more issues preventing normal acquisition of an IP address. These issues include the actual hardware configuration of the base image.


The most common cause when this is the case is a network card either not being available, or not connected at power on. Follow the steps below to confirm whether or not this is the case in the vSphere Client (refer to VMWare documentation for instructions on doing the same in the vSphere Web Client):

  1. Login to the vCenter that contains the base image (Template or VM) for the service from which your VM was deployed.
  2. Locate the base image in the VMs and Templates tree. If the base image is a template, you must first convert it to a VM.
  3. Right-click the VM and choose Edit Settings.
  4. Check the Hardware list. If you do not see a Network adapter listed, this is the problem. The deployed VMs do not have a network card. Click Add and complete the wizard to include a NIC. If you do see a Network adapter, select it.


  5. Under Device Status, if Connect at power on is not checked, this is the problem. The deployed machines have a network card, but the network is not plugged in. Check Connect at power on and click OK.


Additionally, the network card driver selection may be contributing to the issue, if you are using VMXNET3 and deploying Windows Server 2008 or Windows 7 which has not been patched with Microsoft Hotfix KB2344941. For more details, refer to VMWare KB article KB1020078. The simple fix when this is the issue is to update the base image to use only the Intel E1000 driver for its network cards.

Template Software Configuration

The template or VM upon which the service is based may have one or more issues preventing normal acquisition of an IP address. These issues include the configuration of the operating system resulting in a deployed VM not able to acquire an IP address.


Here are some possible causes:

  • DHCP ClientIf the DHCP client is not enabled, but the deployed VM is expected to pick up its address from DHCP (for example, when configured this way as part of a fenced service). Additionally, if the DHCP client is properly enabled, but no DHCP server exists serving the network onto which the VM was deployed, you will get similar results.

  • NIC disabledIf the local area connection associated with the NIC is disabled within the operating system, an APIPA address is used by the operating system in place of the address that would otherwise be used if the NIC were enabled.

Interrupted Customization

When using a vCenter customization spec to configure deployed VMs, if the customization process is interrupted, the VM may be left in a state with incomplete or absent network configuration, in which case the operating system will provide an APIPA address. You can confirm by checking the sysprep files for more information.

To avoid this from occurring, use a completion workflow that includes a Wait for Customization step.


See Also