Ghost Solution Suite

We are preparing an embedded laptop running Windows XP SP 3, installing the OS and then installing a printer driver, including registry updates designed to keep the OS from asking to install every new different copy of the same type of printer when it is attached. Everything works fine. Then it’s imaged with Ghost and that image is restored. Then when a new printer of that same type is attached (or indeed the original printer used to create the driver), it creates a duplicate printer driver and invalidates the old one. The "new" driver works fine for all copies of the printer, but the old driver from the image doesn't work for any copy of that model of printer. Why does this happen and how can we prevent it?

I'm thinking something about creating the image or restoring it might invalidate the printer drivers? Thanks in advance.

I presume that this is a USB printer and that you are restoring the image to a different machine?

My suspicion is that the issue is not with the printer driver but with the USB ports, which are being recognised as "different" ports to the original source machine, and therefore require the drivers to be reloaded. Without examining the hardware and the related registry entries between the two machines it is hard to give a specific diagnosis, but what you could try doing, is exporting HKLM from the machine that holds the initial source image, then restore the image, fix the printer issues, export HKLM again and compare the two REG files, starting with the system areas. Searching the reg files on the printer name is a good way of pinpointing the printer entries, but I would stress that the USB entries need to be compared too.

In this case we are restoring the image to the original machine, but if we were to restore the image to a different machine it would be to a laptop of the same model. The hardware should be identical.

What does HKLM stand for?

HKLM stands for HKey_Local_Machine, which is one of the hives in the system registry where information about applications and hardware is stored. If you are unfamiliar with the workings of the registry then I would recommend you discuss this with someone who is familiar as it is not a quick "learn".

When you restore the image (which I presume has not been Sysprepped) to the same machine, have you checked whether device manager is showing any yellow ticks which indicate that drivers have not loaded?

Also, are you using a local or roaming profile for the user account that is logging in each time?

You have some good ideas there. Yes this isn't my specialty, I'm just helping our systems engineering group generate ideas to solve this problem. I'm not wise in the ways of computer deployment. I do not believe the machines are sysprepped though. I did inquire. 

This is an embedded laptop running Windows XP on an aircraft and the printers are portable printers used by the maintenance crew. There is only 1 user (besides the admin user) installed on this computer. There is no workgroup. The computer is not on the internet so no domain is possible. The user which is used by the aircraft crew is a limited user though there is an admin account for the maintainers.

When Symantec Ghost is used to image a laptop's drive, and then the same image is used to do the restore, obviously my assumption that everything is back to normal is incorrect. At least perhaps this isn't aways true. I passed on your suggestions about checking for non-loaded drivers in the non-working system as well as exporting the HKLM hive before and after so we can do comparisons. What could cause a restored disk drive to fail to load the drivers when the disk which was imaged had the drivers loaded? If it's on the exact same machine how would it even know the difference? Now if it's on an "identical" laptop, then I can see how it WOULD be different because the OS might check and see that it's a different machine by checking the firmware.

I appreciate your help.

When you plug a USB device into a USB port, the plug and play subsystem reads the device ID of the connected device, then looks through a library of INF files on the machine to see if it can find a match for the device ID. If a match is found in the INF file, then the driver information in the INF is read, and used to load the appropriate driver. However, in addition to this, USB ports also have different identities as far as the operating system is concerned, so plugging the USB device into another USB port will cause the driver load process to be repeated. Therefore if I was adding any device drivers to a build that works with a USB device, I would routinely "initialise" every single USB port on the machine with the same device to make sure that the registry contains the correct descriptors for this device on each of the ports.

While trying to find a way of handling mobile phone software for USB connected mobile phones, I also found that each phone had a different identity linked to the IMEI number, and so it was insufficient to just initialise each USB port with a single phone, as using a different phone (albeit the same model) would require a completely separate set of registry keys to be created.

The way I found out what was going on, was to export HKLM and HKCU after each device was installed, and compare how the registry entries were created at each step. Not a five minute job but the only real way to establish what is going on.

I cannot directly provide a solution to your specific situation, as there are too many potential variables, but hopefully I can give you a direction to follow.

If you are testing with the same machine each time, then it should be possible to exclude hardware differences at this point, as variables such as the bios serial number remain constant.

My first test would be to load the image, check device manager to make sure all drivers have loaded and there are no yellow ticks against any device, then export HKLM. Then repeat the process and compare the two registry exports. This should identify if there is any difference in the way that the drivers are loaded viz a viz the USB ports. If you can confirm that the USB ports are mounted identically each time, then that aspect can be excluded as a causal factor.

Then repeat the process after plugging in the SAME printer each time, and check whether the same registry entries are created for each USB port. Then try a different printer and check whether the same registry entries are created, or there is a difference caused by each printer having a unique identity.

From the symptoms you describe, it looks like the printer is being treated as a new device when you plug it in after restoring the image, but what is unclear is why this is happening if ALL the hardware is identical between image restores.

There are some free capture tools you can download, such as InCtrl5 which could be used to snapshot the machine filesystem and registry before and after plugging in a printer, so that you can find out what is changing each time. Once you know, it may be possible to automate this procedure.

Our System Engineers tried building up the OS and the drivers and exported the HKLM and then restored it to ANOTHER supposedly identical computer and exported again. One thing that seems to be the case is supposedly identical computers aren't. There seem to be a lot more diversity with the same model than I would have thought.

Then clearly there is a process I don't yet understand about what happens to a computer when it boots up for the first time with a restored image from the same or from another machine. Obviously the Registry is getting rebuilt. I don't know what the cue is to rebuild it, but it is getting rebuilt. And during that rebuild process, it can create driver entries as needed to make the computer work. This is probably a necessary process, otherwise the computer wouldn't work.

Lastly, in regards for the HP450 printer under discussion, there are no differences between the HKLM export from the original vs. the restored machine prior to plugging in a printer to the restored machine and having it create a second installed printer driver.

I like the idea of plugging in the printer into all the USB jacks too. And one of our system engineers wonders what will happen if he imports the registry from the old machine into the restored machine. I'm think it will just get rebuilt again on the next reboot but I don't really know. We thought we'd try duplicating the problem with the restored machine and then dumping the hive again to see what gets added. And maybe we'll try the import of the registry and do another dump there to see if it does indeed get rebuilt.

Look for printer entries in HKCU as well.

I didn't ask whether the machine was built using a local admin account or a domain admin account, but if you want settings to be persistent then make sure the same account is used for building as for testing - preferably a LOCAL admin account.

Microsoft use a number of techniques to prevent software piracy, and many of these are undocumented. So small changes such as a different bios serial number will indicate that a different machine is being used and may trigger a licensing check. A different machine will also have a different MAC address on the network card, and if the manufacturer happens to have used a different revision of motherboard with perhaps a different chipset, that too may have a different device ID that triggers a rescan of the driver library.

Aside from that, the plug and play subsystem runs at each boot, to ensure that all necessary drivers are loaded.  Since getting the correct drivers for an operating system build can sometimes be a challenge, a while back I wrote this article: https://www-secure.symantec.com/connect/articles/utility-assist-identifying-plug-and-play-drivers  which can be run from the vendor supplied operating system and used to record all the plug and play device IDs and information about the INF files used by each device.  In your project, this could also be used to compare two machines and verify whether their device IDs are the same throughout, because if they are not, then this would cause a rescan of the driver library to find a compatible driver.

You don't mention which vendor you are sourcing your laptops from, but it's not unusual to find that companies like DELL, HP Compaq and Lenovo have changed chipset versions during a production run based on what their suppliers are shipping to them. Thus apparently identical machines always have some differences.

We don't have domain accounts because this is an embedded laptop on an aircraft connected only to a paired server. There is ONLY a local admin account and a local user account (which is what the users use).

The laptops are Miltope ruggedized laptops. They're an older model. It's designed mostly for use in army vehicles.We might try your tools and the printer entries in the HKCU hive as well. Thanks.

Do you use deployanywhere with ghost?   Simular to what Sysprep is supposed to do for prepareing a systmem to run on different hardware it will change certain drivers and engage a redetection of hardware.   If these really are all the same model machine I would think that microsoft sysprep and Symantec's Deployanywhere step could be skipped if it was being used and their may be better results.  

The OS is going to try to redetect certain things no matter what after it is cloned because even the same model machine will have differences like the MAC address for the network card and the bios settings may not be the same and also will trigger a rescanning for new hardware and that may again break your fix that was deployed in the first place.  

Cheers,

I think we just create an image with Ghost and then restore it to the same or other machines of the same model. We create a DVD which contains the Ghost program and the image so that it can be put into a drive and used to restore the machine to the original image.

Yes we're certainly getting that rescan.

Now we're thinking it's possible that it's the multiple USB jacks that are doing it to us (As EdT said above). We install the printer using one USB jack and then doing the restore and plugging it in to the other USB jack. Even doing the whole thing without the restore seems to create a new copy of the printer driver despite our fix. We've been looking into that option too, but the whole process is pretty slow. How do you prevent that though? I mean you can't just install it on both USB ports because you'd have two installed printers both called the same thing? Or would it be smart enough not to do that if the printer was the same printer?

Unfortunatly I don't know how to get around the new printer found issue with HP.   I have a relation who has an HP printer that seemingly randomly redetects even though the system is not moved or unplugged it is a desktop and she is up to new printer #30 or something like that now.   I gave up and just showed her how to set the newest one as default and it works luckily for her.  

I have worked on similar builds for a major broadcaster, and made sure that I initialised every USB port on the machine with the target printer type(s) before taking the initial image.

I agree with ICHCB that there are a few printers that appear to create multiple printer entries for no apparent reason, and can attest to having problems with some HP drivers as well.  What I would recommend is that you check that you are using the latest printer drivers for the printer you are using, and also spend some time browsing the user forums if the printer vendor has them, to see if other users have reported those exact issues.

As our experimental procedure refines, our latest test shows that even when we build up the OS and don't image it, even when we install the printer on one USB port and the registry fix seems to work, when we plug it into the other port it duplicates the printer driver.

Any ideas on how to prevent this USB duplication?

This looks like a bug in the printer driver. Have you followed my earlier suggestion about checking whether you have the latest printer driver and whether there are any vendor forums where you can find out whether there is any known resolution for this.

Perhaps if you were to share details of the printer you are using and details of the driver version you have tried so far.  Untimately, this is not a Ghost issue, but of course if I can be of further help then I'll do what I can.