I cloned a vmware machine on vSphere client, which meant I needed to run NewSID or sysprep to change the SID. As newSID isn't available any more, I ran sysprep without checking the generalise option, this didn't solve the problem (inconsistent sid), so I ran it again but chose the generalise option this time. This solved the problem, but for some reason created another - the server won't configure the static IP address that I assigned to it - it uses a 169 address instead. If I choose to have it automatically assigned an IP it picks up the correct address. There isn't anything wrong with my network, the problem will be on this box.
I have quite proficient networking skills, but this problems eludes me. No other servers have this problem, just the cloned one.
I carried out the manual TCP/IP stack reset here which seems to have done the job. I've never some across this before, just luck I found it so quickly.
I've found that two approaches work well with 2008 and ESX:
Something about SysPrep doesn't create a fresh "GUID" for the NIC virtual hardware, which causes a problem.
I had this happen on a 2008 R2 server also. The server has 3 ethernet adapters. 2 where "disabled" but plugged into the switch and 1 was in use with a static ip address.
I access the server without issue using the static ip and when you did a ping from another computer on the network of the servername it resolved to the correct static ip. However, when you did a ping from the server itself it came back as 169.#.#.# which is the address it returns on a failed dhcp assignment.
What I ended up doing is unplugging the ethernet cable on the 2 "disabled" ethernet adapters. It just magically fixed at that point. Go figure. Disable doesn't necessarily mean disable. Then I did a "reboot" to see if it would stay. It did not.
Ended up putting an entry in c:\windows\system32\drivers\etc\hosts to force it to the static ip. Sometimes one just works around and then moves on.
I tried the fixes listed above but none worked.