Jump to content

redia

Member
  • Posts

    4
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    Switzerland

About redia

redia's Achievements

0

Reputation

  1. Not using sysprep, using Driveforge, not deleting the drivers folder, either. Source is USB or CD, destination is folder at root of local system drive. Today I found that by modifying the registry back to the %systemroot%\INF folder, then restarting, then rediscovering hardware after removing the yellow exclamation points, it discovered them correctly. I don't know why, it seems like DriveForge maybe installed drivers for the monitor that didn't work correctly, then the default INF just made it a plug and play monitor, maybe, and that was better or something. Also, IDK why driverforge leaving the default driver folder to the uncompressed drivers means that it can't recognize things as simple as a USB key w/o changing it back to the INF folder. Anyway, I can't really give the computer back to a client w/o switching the registry back to the INF folder, so that'll be cool when that tweak is done, IMO. tslug, which version of driverforge are you using ? kickarse is already working on solving the devicepath issue, so he will probably release it very soon. but if I am not mistaken he is also adding a couple of new improvement which could explain that the version has not been released yet. until then you can simply script the modification in the registry i.e. save devicepath status run driverforge restore devicepath I advise you to save/restore because in most of the cases you will have %systemroot%\inf but in some rare cases the device path might already contain different values.. so save/restore covers all cases Cheers, R.
  2. Tslug, are you using sysprep ? or are you deleting the drivers folders ? Kingskawn, are you deleting the drivers, or are they accessed through the network before sysprepping ? the issue here is very "simple" or at least straightforward when running the sysprep all the drivers are "cleaned" and when restarting the computer it goes through a discovery phase. most of the drivers would work, but unfortunately due to the way the driver inf are built sometimes some leftover are included in the registry pointing to the "uncompressed" driver files. I have face this type of issue. and it has nothing to do with driverforge. my way of dealing with that is as follow : after driverforge running (and I do not delete the drivers in the program) I run a script that I did build: - it simply check (using devcon) for the existence of specific hardware that I have tested to create this problem, - copy the drivers in a local directory - modify the registry accordingly to make sure next time it will look for the correct location - delete the uncompressed driver folders. this way I minimize the amount of drivers kept locally on the computer, and through this I minimize the size of the image. how do I find the problematic drivers ? well simply by testing. so the first computer of a type that I create brings up the errors... afterword it is easy to deal with. how hard does it go.. well it ends up being pretty fast, and you will notice that very often it is the same drivers that are creating problems, in my case solving 1 network driver solved the issue for 4 different type of computer. I am looking into a more systemic solution that we could use in coordination with driverforge : a pre-script that would delete all the unneeded folder, thus by simply choosing not to delete the drivers after running driverforge we should not face the problem again. but I have to really dig into that as it really depends on the way the drivers are structured. if I end up finding any constructive way to do it I will share my findings with kickarse so we could see whether he want to include it in his soft or prefers to keep it outside. do not expect any update in a short period of time as I have a ton of things to do first. anyway if anyone need help on how to manually do it, or want a copy of my script let me know, it is a first step... Cheers, R.
  3. this is an interesting idea. the only thing is that it might be difficult for Kickarse to know what each file stands for. most of us are using driverpacks file.. but I also use my own pack.. and the driverpacks are updated so the filename might end up changing. about this point you are right. I am sure Kickarse will modify that. on my test the devicepath is "c:\windows\inf;c:\drivers\3\mo\a;c:\drivers\3\mo\b...................." but to be on the safe side the devicepath should not be set to "c:\windows\inf", but %systemroot%\inf (to cover the installation in a different folder), or even better, restore the previous value.. R.
  4. 0xFFFFFF, I am running into the same problem as you for the homedrive homepath issue. I am coding a small autoit proggy to solve this. you will simply need to add it to the default user runonce.... simple and easy. no fancy thing. if you are still in need of that simply PM me. R.
×
×
  • Create New...