Using wildcard seems to strip out someting needed for NIC's Static IP's

Feb 4, 2015 at 5:52 PM
Love the tool. We clone a lot, so this is Step 1 after the clone, remove all the ghosted devices. Used to be a tedious manual process.

But, recently (last 12 months) we are running into an issue we've narrowed down that starts after we run Ghostbuster. We use * as a wildcard, and remove all ghosted devices. The problem did not exist prior, we have been using Ghostbuster for years.

If the workstations or Server OS (seen it in Windows 7, Server 2008R2, Server 2012 and Server 2012R2) is Static IP'd and we run the usual remove all ghosts, we see this problem:
  • Before you reboot, you can still go and see the Static IP information on the usual Microsoft NIC properties page
  • After you reboot, you will see the NIC properties page will be set to all DHCP. BUT, if you do an ipconfig command you will find the NIC is still set to the original Static IP
  • If you try and change the DHCP page to Static and put in all the same info, it won't let you since the same IP is already in use.
  • If you try and change the DHCP to static, and use a new IP address, it will accept the information. When you hit OK to save all the data, and then reopen the NIC properties, it will be back on DHCP, but if you IP config, you'll find your NIC now has both the original and the 2nd IP you just tried (making matters worse).
  • We've tried all sorts of various tweak, resetting stacks, removing NICs, changing drivers, but none clear the issue.
  • We've seen the issue in both physical and virtual server environments
  • We ultimately found this in most cases this can fix the issue:
    Open regedit and go to: HKLM\SYSTEM\CurentControlSet\Control\Network and there you will see a sub key called “Config” Delete this key and then reopen the IPV4 Properties and you will see the correct information.
We noticed that the view of the protocols in the network properties list shuffles when we do this, but at least this has restored the ability to edit NIC settings, etc.

We aren't sure if its 100% repeatable to generate the issue on a virgin platform, but we've seen it several dozen times, and we've stopped using Ghostbuster now :<(

So, there's our sad story. We've tried to solve it on our own, figuring there is some key that Ghostbuster shouldn't be deleting that does this, but we've not solved it.

Not trying to cry wolf, we love the product. We did think that maybe the issue is real, and since DHCP is the way most people have their hardware set, maybe its not been noticed our brought up by others.

Anyways, since it appears that you monitor the forums and really care about the product, thought I would detail it here and let you know. If you want to look at a system with the issue, we can probably arrange that. Maybe you can reproduce in house.

Thanks!
Coordinator
Feb 6, 2015 at 11:01 AM
Edited Feb 6, 2015 at 11:06 AM
Hi

Sorry to hear GhostBuster is causing you problems.

I'm not sure what I can do then what GhostBuster do is uninstall devices and (besides the new serial port clean-up option) it does not alter the registry directly but it asks Windows to uninstall the device. It does the same as removing the devices in the device manager manually (but not one by one).

So what happens is that somehow the devices .inf file that is used does not clean things up. My guess is that the static dhcp is not the default when installed and Windows/the .inf file only removes the unchanged keys (that's how a normal uninstall works).

To see if that's the case you could try to remove a network adapter manually, reboot and see if the settings are still wrong. Another issue might be the order in which GhostBuster removes devices (in order of enumeration), it would require some manual experiments. If so you could run GhostBuster with different settings multiple times.

You could also try if you can set the IP address to DHCP prior to running GhostBuster using powershell or so. See this page and this page for some related code examples.

Finally note that using a wildcard like * is not supported (as I have no clue what can go wrong). GhostBuster will also not remove devices that are marked as services (despite the wildcard).

I'll have a look into the registry and see if there are any clues there (I want to keep registry modification to a minimum as you might understand).

regards
wvd_vegt
Coordinator
Feb 9, 2015 at 10:17 AM
Hi

If you send me a PM with your e-mail address we can perhaps see if I can be of any help solving this (I will need some more registry info for instance).

regards
wvd_vegt