Due to a quirk with the way our TMG server is set up, we reboot it every morning at 6AM to prevent it prompting for usernames and passwords (it's a weird issue). Yesterday morning, when it rebooted, it lost its network connection to the local network, and we had to log in to the IP KVM to get at the console. From there, we simply restarted it, and it was fine. This morning, the same thing happened, and on investigation, the server had acquired a DHCP lease from our DHCP server (we currently don't have VLANs or a dedicated server network - coming soon!). The wacky thing is, the TMG server should never have requested a DHCP lease. Not least because it has a static network address set on the adaptor... or we thought it had. It did have a static address prior to yesterday morning's reboot. It then rebooted, at which point, for some completely illogical reason, the following event shows up in the event log: Event ID: 20003 - Driver Manager has concluded the process to add Service b57nd60a for Device Instance ID PCI\VEN_14E4&DEV_165A&SUBSYS7051103C&REV_00\6000A12B660A10B00 with the following status: 0 A similar entry shows up this morning: Driver Manager has concluded the process to add Service b57nd60a for Device Instance ID PCI\VEN_14E4&DEV_165A&SUBSYS7051103C&REV_00\202073FFFEA8440300 with the following status: 0. Note the different Device Instance IDs. This, of course, leads to Windows going "AH! New adaptor! I'll do DHCP on that", and all hell breaks loose and down goes our internet access. Has anyone seen this before? I'm thinking it's a hardware fault, but am praying it isn't.

Check below link and troubleshoot event ID:20003 accordingly. Event ID:20003 Service Installation-http://technet.microsoft.com/en-us/library/cc756321(v=ws.10).aspxRegards, Ravikumar P

The problem is, it's successful, and the event shouldn't ever be firing..... There is no new hardware, it's the same bit of hardware that's getting reinstalled for no reason.

Install latest drivers for NIC's and check for the difference.Regards, Ravikumar P

Seems to have done the job - will continue to monitor and report back after Monday's reboot.

Sadly that wasn't enough. We're biting the bullet and virtualising the server on a fresh build in an effort to try and fix the issue once and for all.