As part of the install process, Windows 10 saves a copy of the previous installation files in case the system needs to revert to its original settings due to an error during the upgrade, or you need to rollback because of a problem after the upgrade.While it's a useful safeguard feature, the files (stored in the Windows.old folder) can take up a fair amount of disk space.
Jul 05, 2017 Device driver packages: Windows keeps old versions of device drivers, whether they were installed from Windows Update or elsewhere. This option will delete those old device driver versions and keep only the most recent one. You can remove these files if your PC and its devices. The Disk Cleanup tool Once you launch Disk Cleanup, if you have more than one hard disk in your system, you'll be prompted to select drive C. Disk Cleanup will begin to analyze the files on your.
When ever I make a image right before I perform the capture I run disk cleanup to remove any unneeded files. I have noticed that when I did this with Windows 8.1/10 that the Device Driver Packages is rather large (about 9GB) and I would like to free this space up (Windows says that it contains previous versions of drivers).However with the way that I make our image is I inject every driver for all our systems into MDT have it add them to the drive store. My question is if I clear up the Device Drivers Packages from disk clean up does that also remove drivers from the Driver Store which the other models in our fleet use when they go through their setup phase? Kfberns wrote:Well I can't answer your question directly but I have to ask why you are worried about 9Gb of space?
Most new systems come with 500Gb drives. It hardly seems worth the trouble especially when you consider that the end user will be pilling on tons more just through normal use.Because our newer systems have SSD with the smallest of them being 128GB and once the image is deployed there is only about 30GB of free space (our image is massive and contains the full Adobe Master Collection Suite as well as several AutoDesk products). No drivers should be in the reference image and it is best to make the reference image in a VM because it is cleaner, faster, and you can make snapshots right before capturing. With this said when sysprep runs it strips away all known hardware (and drivers) from the reference image before capturing.
Using MDT to inject the drivers is the proper method. The timings your posting on imaging based on hardware speed sounds about right to me.
Also depends how many apps you have baked into the reference image. With Autodesk apps it does not surprise me that the reference image is fairly large. I have been watching some videos on plural sight by Johan Arwidmark and he suggests organizing drivers by manufactucter and model in the mdt driver store. He then runs a script on each client to determine what folder to use to get the drivers. Jago can probably answer this, does the client pull down all of the drivers in the store or only the needed ones? I'm not sure why the videos recommend organizing drivers this way unless it helps in speed in determining which folder to search instead of all, or if it determines if all the drivers get pushed to the clients in the driver store or not.
As Jago suggested above, Johan also recommends creating the image on a VM to get the most hardware independent image possible.As you state above, you are concerned with your driver store getting larger and larger on the clients as you push more drivers into the store. Hopefully my comments above spark some replies to your question as I am curious as well. Jago Wu wrote:No drivers should be in the reference image and it is best to make the reference image in a VM because it is cleaner, faster, and you can make snapshots right before capturing. With this said when sysprep runs it strips away all known hardware (and drivers) from the reference image before capturing. Using MDT to inject the drivers is the proper method.
The timings your posting on imaging based on hardware speed sounds about right to me. Also depends how many apps you have baked into the reference image. With Autodesk apps it does not surprise me that the reference image is fairly large.I cannot use a VM as the Lenovo software detects that it is not being installed onto a Lenovo machine and then quits the installation process. I do not believe the sysprep strips away the driver store but it does make it so that the image becomes hardware independent and free to be installed onto any other hardware.
We currently use WDS for deployment and MDT for create and capture. I have used WDS's ability to inject drivers at install time but I feel it isn't as good as MDT's and have run into some problems using it in the past.
Phil435 wrote:I have been watching some videos on plural sight by Johan Arwidmark and he suggests organizing drivers by manufactucter and model in the mdt driver store. He then runs a script on each client to determine what folder to use to get the drivers.
Jago can probably answer this, does the client pull down all of the drivers in the store or only the needed ones? I'm not sure why the videos recommend organizing drivers this way unless it helps in speed in determining which folder to search instead of all, or if it determines if all the drivers get pushed to the clients in the driver store or not. As Jago suggested above, Johan also recommends creating the image on a VM to get the most hardware independent image possible.As you state above, you are concerned with your driver store getting larger and larger on the clients as you push more drivers into the store.
Hopefully my comments above spark some replies to your question as I am curious as well.I currently have all the drivers arranged in nice little folder for each make, model and OS version. This is more of an organisation thing for me but does come in very handy when you want to run selection profiles or other such things. As for whether all drivers get pushed down to the machine or only the ones required that is actually up to you. You can set up a driver selection profile such as 'All Lenovo Drivers' and then set the driver injection task sequence to either install all drivers you the selection profile or only the required drivers. This way you can have all your Lenovo systems using the 'All Lenovo Drivers' profile but only installing the ones that are needed for each model or as I do stick them all in.
Phil435,By default, MDT will utilize its PNP detection and try to match the drivers and hardware up best as possible. Sometimes this will work and other times it will not. I recall in the past how a mouse trackpad driver from a laptop kept getting installed on desktops. That is an example.
There are two way to avoid this to take control of drivers so you know exactly what gets injected per model. One way is with Selection Profiles and other is DriverGroups.
Johan is OSD master to me.BWMerlin,I personally do not see how it is a problem to check all boxes on disk cleanup. Also with the cleanup of system files. I do this myself even though I'm on Win7. I also visit%temp% and C:windowstemp and delete files from those two spots.The Lenovo software you are speaking of you need to create a silent installation for that package. Please do not let this stop you from VM.
We have many people here on this forum that can help you with the silent command line switches. If you have a link to download the Lenovo software I can take a look at it myself.Sysprep will strip the reference image of drivers/known hardware as long as the /generalize switch is used. This was the beauty of Sysprep since Win7 is we are no longer bound by model per image.I strongly recommend you use MDT to also deploy the image as it is much more flexible and provides an end to end imaging solution. WDS just pushes one static image pretty much.
Just to add to the discussion a little:. Sysprep doesn't remove drivers from the image. It removes device installations. Even some of Microsoft's own documentation screws up this nugget of knowledge, which is amazing, so I am really not surprised when someone doesn't know this. If you have a driver in the driver store, Sysprep will not remove it. However, if you had, say, a USB keyboard attached, it will remove that installation instance from the device-installation history, so when you plug in the keyboard after Sysprep, it has to re-recognize it as if it had never been plugged in before. MDT has one really major drawback: no multicast.
If you need to do an entire lab of computers (say, 100 computers at a time), MDT is a no-go. All of the Microsoft solutions basically have one big disadvantage: no multicast of drivers. That's not a big deal for tens of computers, but if you're doing hundreds or thousands of computers and need them done in a matter of minutes, you basically have to include the drivers with a multicasted image, or it's going to take forever to get the drivers.Right now, we put the drivers inside the image but not necessarily all in the driver store:. For driver packages that have numerous drivers (like Intel's video drivers), we currently include them in the driver store via PNPUTIL (with the -a switch to add them but without the -i switch so they are not installed). I really do not like doing this, but Intel includes so much crap in its driver packages that it's really hard to get just the video driver files that you actually need from the package. I see the INFs in there, but damn if I know which ones to grab. These drivers will be recognized and installed by Sysprep's mini-setup when the image is deployed.
For driver packages that have a very small number of drivers (usually network drivers, SATA-controller drivers, etc.), I install them after deployment with a script using PNPUTIL by detecting the computer model (with both the -a and -i PNPUTIL switches so these drivers are immediately installed). The reason why people tell you to make your image in a VM has more to do with the extra crap that some drivers install more than the drivers themselves. Intel, for instance, adds its own context-menu stuff. In theory, if you never installed any of that stuff (and KNEW that it wasn't installed in the background without your knowledge), a physical hardware image would be just as clean. A VM also has the added benefit of snapshots and portability.You can multicast your image itself, but to my knowledge, you can't multicast drivers.
That's why I include them in the image, since they are multicasted that way. It only takes about 10 seconds for the script to delete them afterwards.We actually don't use MDT or WDS for the most part. For our employee machines (which there are much fewer of), MDT is realistic. For our public computers (of which there are thousands), we use FOG. Oh, I definitely agree that a VM is better 99% of the time. We've had a few instances where we really had to use a physical machine for a specific image. For example, we've had to put out images with 3D-intensive CAD software and needed to configure settings, and the software refused to even run on the VM at all.
That's rare, though.My understanding (could be wrong on this - don't quote me) is that the hardware detection happens locally on the machine and is injected by Windows PE. So, I believe the image itself (which is the same for all machines that are being deployed to) is multicasted, while the drivers (which are device-specific) are unicast to each machine since you may not be deploying all to the exact same type of machines. Jago Wu wrote:Phil435,By default, MDT will utilize its PNP detection and try to match the drivers and hardware up best as possible. Sometimes this will work and other times it will not.
I recall in the past how a mouse trackpad driver from a laptop kept getting installed on desktops. That is an example. There are two way to avoid this to take control of drivers so you know exactly what gets injected per model. One way is with Selection Profiles and other is DriverGroups. Johan is OSD master to me.BWMerlin,I personally do not see how it is a problem to check all boxes on disk cleanup. Also with the cleanup of system files.
I do this myself even though I'm on Win7. I also visit%temp% and C:windowstemp and delete files from those two spots.The Lenovo software you are speaking of you need to create a silent installation for that package. Please do not let this stop you from VM. We have many people here on this forum that can help you with the silent command line switches. If you have a link to download the Lenovo software I can take a look at it myself.Sysprep will strip the reference image of drivers/known hardware as long as the /generalize switch is used. This was the beauty of Sysprep since Win7 is we are no longer bound by model per image.I strongly recommend you use MDT to also deploy the image as it is much more flexible and provides an end to end imaging solution.
Jasonfreeman2 wrote:Just to add to the discussion a little:. Sysprep doesn't remove drivers from the image. It removes device installations. Even some of Microsoft's own documentation screws up this nugget of knowledge, which is amazing, so I am really not surprised when someone doesn't know this. If you have a driver in the driver store, Sysprep will not remove it. However, if you had, say, a USB keyboard attached, it will remove that installation instance from the device-installation history, so when you plug in the keyboard after Sysprep, it has to re-recognize it as if it had never been plugged in before.
MDT has one really major drawback: no multicast. If you need to do an entire lab of computers (say, 100 computers at a time), MDT is a no-go. All of the Microsoft solutions basically have one big disadvantage: no multicast of drivers. That's not a big deal for tens of computers, but if you're doing hundreds or thousands of computers and need them done in a matter of minutes, you basically have to include the drivers with a multicasted image, or it's going to take forever to get the drivers.Right now, we put the drivers inside the image but not necessarily all in the driver store:My next project, which nobody seems to know much about, is trying to do the PNPUTIL -A during one of the Sysprep passes based on the computer model.
If I can do this, it would basically ensure that only drivers related to the computer model even get put into the driver store, which would obviously be ideal, and it would ensure that Sysprep's mini-setup does the detection and installation, which I have found to be the most consistent and reliable.However, I don't know enough about the Sysprep passes to know if this is possible and, if it is possible, which pass to put it in.Wow, lots of points there. My question to you is why not just load all the drivers into MDT and then use the inject drivers phase to only install drivers that the systems needs or use a selection profile to once again only inject that models drivers.
To me that seems the easiest way.As for multicast, we don't use it. We have tried it several times with WDS but it works out much quicker for us to just unicast an entire lab/group than multicast it (a lot quicker to unicast).As for sysprep removing the installation and not the driver store I was aware of that but still unsure as to whether the disc clean up device driver packages are unused driver store drivers that it wants to remove (I suspect they are).
BWMerlin wrote:1. Wow, lots of points there. My question to you is why not just load all the drivers into MDT and then use the inject drivers phase to only install drivers that the systems needs or use a selection profile to once again only inject that models drivers. To me that seems the easiest way.2. As for multicast, we don't use it.
We have tried it several times with WDS but it works out much quicker for us to just unicast an entire lab/group than multicast it (a lot quicker to unicast).3. As for sysprep removing the installation and not the driver store I was aware of that but still unsure as to whether the disc clean up device driver packages are unused driver store drivers that it wants to remove (I suspect they are).1. Well, for MDT alone, there is no multicast.
With WDS, I believe WDS unicasts the drivers separately from the image. Or at least we've had performance issues related to drivers in our testing.2. Unicast is not, in any scenario, faster than multicast. You were doing something very wrong. We can multicast 200 machines in the exact same time it'd take you to unicast to one machine. Quite literally, when you multicast, the server is sending out one copy but having the switch do the work of getting it to all the machines.3. Try it and see.
Device Driver Packages Disk Cleanup 2017
Jago, right, but are you actually doing settings of the CAD software in the image?EDIT: I see where you said that you don't need to open the software. That's the difference. We have instances where we have to actually perform settings configurations in the image, and a lot of that simply cannot be done in a VM.
Certain things simply won't run without full-blown 3D acceleration; in fact, some software goes as far as to check which driver version you're running to see which visual features are available.On employee machines, this is typically not an issue because the employee can customize the software however he/she likes, but it is an issue on our public computers that we have. Jasonfreeman2 wrote:2. Unicast is not, in any scenario, faster than multicast.
Device Driver Packages Disk Cleanup Download
You were doing something very wrong. We can multicast 200 machines in the exact same time it'd take you to unicast to one machine.
Quite literally, when you multicast, the server is sending out one copy but having the switch do the work of getting it to all the machines.We have tested this many times and it massively slower. We have thought that it maybe the switches (D-Link) so once the new gear (CISCO) is in we shall give it another shot but for now unicast by far is our fastest option.