Video Screencast Help

Windows 7 x64 doesn't have network drivers after successful GhostCast deployment

Created: 30 Apr 2013 | 8 comments


I have a Dell Optiplex 790 that I am having network driver issues with post-GhostCast.

WinPE-512 and DeployAnywhere both have all of the correct network drivers for the Intel 825xx network card (both 32-bit and 64-bit, separated out for XP, Vista, and 7). I am able to successfully deploy the image to the machine, and it boots successfully into Windows 7 x64.

Unfortunately, once booted and logged-in, Windows does not have the appropriate network driver installed. I assume there should be a way for Ghost to install the proper Windows 7 x64 network drivers during a GhostCast. Can someone assist me with a way to do so?

I can always log-in and install the drivers manually once the new OS is booted, but this would be a pain to do on multiple machines.




Operating Systems:

Comments 8 CommentsJump to latest comment

EdT's picture

Please tell us more about how your image was created. Is it a sysprepped image, for example?

What version of Ghost are you using?

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

jbotto's picture

Sorry for the delay in response!

This is using Ghost Solution Suite 2.5

I have a VirtualBox VM running Windows 7 x64, on the same server as GSS 2.5. I am taking a sysprepped image from the VM.

Please let me know if there is any other information you need.

EdT's picture

I am going to post some past discussions on VirtualBox related issues, in case they have any bearing on the situation. Also, it would be helpful to know what Sysprep switch settings you are using. When deployed, does the image still contain the driver library folder?


VirtualBox, like VMWare and Virtual PC, emulates the SMBIOS specification. One of the things the SMBIOS specification includes is a way of determining for a machine a unique identifier - and this identifier is defined, and required to be, *genuinely* unique.

Because for physical machines this is the best - and in fact, just about only - way to reliably determine machine identity, this is naturally the primary identifier used. Therefore, whether for a physical machine (where Dell often to get this wrong and manufacture machines which don't comply with the specifications) or a virtual machine, the uniqueness of this identifier matters.

All the virtualization systems generates UUIDs for VMs automatically; VMWare is particularly clever in that it also generates an ID based on the pathname at which a VM resides, so that when a machine is moved or copied it will detect this when the VM is opened and if you say the VM is copied it will generate a fresh UUID for the contained system to distinguish it from the original.

For VirtualBox, not just VMs but disks have UUIDs attached as well (and those UUIDs are registered at machine scope in the VirtualBox media manager) and so anyone familiar with VirtualBox will inevitably become au fait with the need to refresh/update them as well - unlike VMware none of the UUID-related processes are automatic but need to be scripted.

All this is covered in the VirtualBox manual; since the management system trusts that if an SMBIOS UUID exists that it is unique (unless proven otherwise, for the benefit of Dell systems, where MAC addresses are used as a secondary key to prove that the UUIDs are untrustworthy) and since the MAC addresses are also identical, there is NO WAY for the management systems to know which machine is what unless you ensure that the virtual machines can be reliably given some form of unique identifier.


As per the thread EdT linked, the primary identifier for machines is the SMBIOS UUID. There are still a tiny number of machines (mainly Dells) out there in the marketplace that have been incorrectly manufactured with duplicate UUIDs, but I have not seen any machine at all manufactured in the last 5 years that siomply doesn't have one. So, a good starting point is to determine the SMBIOS configuration of your machines.

[ From memory, I left in a command-line option in the ngctw32.exe option, -uuid or something like that, which printed out the UUID it retrieved; from Windows XP on up, this should be being retrieved via a kernel-level WMI interface or via a similar API introduced in Vista and up. ]

There is, internally to the management system code, a table used for known-bad manufacturers that do not play by the IEEE rules; the VirtualBox adapter definitely deserves to be there, See this; some random company's MAC OUI registration is used instead because basically they never bothered to follow the IEEE rules (or even better, use the specific "privately managed" part of the MAC address space).

While that table of exeptions it's small I did add things over time to it - however, that was done on an as-needed basis and because of the SMBIOS UUID the number of customers affected by this was zero until some time after Symantec had cancelled the GSS product and laid off the original development team.

So, while it's in principle easy to add to the blacklist, in practice you are far better off trying to determine whether your machines do in fact have SMBIOS support and whether their SMBIOS UUIDs are unique

Virtual Box is very messy with its networking components; Virtual Box creates a virtual nic in the host OS when it installs. You can actually see it if you go to Device Manager or run "ipconfig /all" in the command line. I've noticed it does like to go out and grab an IP address even when there's no vm running. The Ghost client is likely getting confused between the virtual nic and the actual nic.

If you really want to confuse the snot out of the console, try installing it on both on a host and a guest os.

I've actually never had reliable luck with msi installers. The console has a remote client install that works beautifully on domain machines, as well as a remote client uninstall. You could try the remote uninstall on the machines that you're having trouble with, to see if it clear your woes out.


Virtual Box only cause this problem with my I7 system, all other system doesn't have this problem; ghost console effectively recognize the NIC as virtual and doesn't use it, like it should

As explained above, this is because the primary key that the Ghost console uses is the SMBIOS unique machine id. As long as the host machine has a valid SMBIOS UUID present, then that will be used instead. As long as SMBIOS UUIDs are present and distinct, NIC MAC addresses are only used as a fallback.

VirtualBox guests mainly cause problems in this respect because VirtualBox's default is to preserve UUIDs of created machines, whereas VMWare quite sensibly watches our for when guest VMs are no longer running on the original system when the guest VM was created, and by default will create a new SMBIOS UUID for the guest (this is the primary function of the "have you copied or moved the virtual machine" prompt when starting a VM in VMWare).

[ Using VirtualBox, ensuring that guest UUIDs stay distinct in the presence of deployed images is awkward, unless you explicitly use the teleporting feature which ensures the -hardwareuuid setting doesn't need to be used or otherwise try and take care of UUID management yourself. ]

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

jbotto's picture


Thank you for your reply!

In SysPrep, I have toggled the following settings:

License Key, Registered User, Registered Company, Network Location, Join Domain (and credentials).

Skip EULA is checked, Skip User OOBE is checked, Keep existing PNP drivers is checked.

Skip Rearm is NOT checked.


Where on the deployed machine would I check to find the driver library folder?

KlausJ's picture

I really have to ask - why use sysprep before ghostcasting?


Whenever I want one or more identical computers to have the same contents, I create a ghostcast image of the first PC to a server/workstation...and then ghostcast back to X number of computers. With ALL drivers, updates and settings etc. intact.

jbotto's picture

@KlausJ: I'm using GhostCast as a way to push a sysprepped image (captured from a Virtual Machine) onto brand-new physical machines. Is there an easier way to do this? 

EdT's picture

@KlausJ - I guess it depends on your environment and whether you use MAK keys or have a KMS server. I'm sure you are aware that Windows 7 is pretty good at spotting that it's been moved to a different machine even if it's the same model.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

KlausJ's picture

The way I usually do it, is by installing one of the identical computers, with all settings, updates etc. I do not want to use a different computer model with different drivers etc. as an origin for any ghost image.

When an identical PC has been installed, I ghostcast an image from that PC...and save it onto a workstation/server. That image is then sent to the other identical computers, also via ghostcasting. And this simple method has been working for many years :)

When cloning any Windows (except Windows 8), be sure to use either volume licensing (or better, hardware dependant licensed Windows). OEM won't work.

Windows 98 to XP uses simple SPL. Windows Vista+7+2008 (R2) + 2012 uses SLIC. All these allow for cloning Windows to other identical PCs/servers. Windows just a train wreck when it comes to licensing. Along with Office 2010/2013, you have to use a KMS server. And..."best" of all, when you clone Windows with Office 2010/2013 KMS, you have to run a rearm after cloning to allow the KMS server to see the different Office installations. Needless to say, Microsoft is doing all it can to push people away from it's biggest cash cow - Office.