I've got an issue where a Windows 2008 R2 Standard (SP1) server loses its static IP configuration upon a reboot. It's a sysprep'd image.

The following steps reproduces the problem:

  • Using the SAC, set the IP using 'i'
  • Use the Win32 EnableStatic() method to set an IP (and then SetGateways()) through PowerShell
  • Reboot

The machine boots up with the following configuration:

Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : [...]
   Autoconfiguration IPv4 Address. . : (incorrect)
   Subnet Mask . . . . . . . . . . . : (incorrect, was set to /24)
   Default Gateway . . . . . . . . . :     (correct)

Occasionally, the gateway is also incorrect (

The images have a script that runs 'netsh int ip reset' after sysprep finishes (before the reboot), so it appears that does not solve the issue. (the problem also happens without this step)

After the reboot, using 'i' on the SAC resolves the issue permanently. (But I'd like to know the root cause as having to run 'i' again isn't ideal)

  • 4
    netsh int ip reset blows away all networking configuraitons, just so you know. Jun 1 '12 at 15:02
  • What do I need to do except set the IP, subnet mask and default gateway (via EnableStatic and SetGateways) to undo a netsh int ip reset?
    – Andrew
    Jun 1 '12 at 15:20
  • Also, I added the 'netsh int ip reset' to try and resolve the issue. I had the same problem before (I modified my question to clarify - sorry!)
    – Andrew
    Jun 1 '12 at 15:22
  • To clarify: when the system reboots and the TCP/IP configuration is lost, is this the first time the system has been rebooted after running sysprep? If so, I think this is normal behaviour. You need to wait until mini-setup has completed before you can configure the TCP/IP settings. Jun 4 '12 at 4:19
  • This is after sysprep has run and rebooted, i.e. the 2nd reboot after sysprep.
    – Andrew
    Jun 5 '12 at 9:25

I actually had a customer that had a similar issue from an image from our PXE server. I spent months banging my head against the desk to figure out why. We ended up deciding that the customer just needed to reinstall as we cannot find the root cause. To this day the customer is still running that OS. What we did do was had a powershell script that runs on startup that configures the interface as a work around and the customer has been happy ever since but we have a note on there account for this issue.


Why not just use the route command with the -p (persist) flag.

route -p add mask

This will ensure the route survives a reboot.


I would try using netsh to set your NIC settings rather than the GUI to see if that helps.

Problem could be registry related. Take a look at the key for your nic in hklm\ccc\services and see if it shows all of your static settings.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.