We are having a really frustrating problem here in our school district.
We are running SCCM 2012 on a server 2012 vm.
We have 48 Distribution points.
Most of the computers in our district are Lenovo.
We are using OSD to image them.
We have noticed that when we create a driver package for a new model, the driver package for a previously working model seems to "break". The logs left on a machine indicate hash mismatch for the driver package.
The most recent chain of failures went like this.
At the beginning of the week, I was able to successfully image Lenovo L440 laptops. The computer would get the os, drivers, install all apps and join the domain.
I built a driver package for a Lenovo x130e-0627, added it to my task sequence, and then tested to make sure that it worked, and it did.
Later that day i tried to image an L440 again and it did not get the drivers, apps or join the domain. I checked the smsts.log file and found a reported hash mismatch on the package that contains the drivers.
I removed the L440 package from the DP i was using, waited for it to be gone, verified with content lib explorer, then redistributed the package to the DP, verified again with content lib explorer. I got the same error when trying to image.
I delete the driver package from sccm, removing the imported drivers, deleting all the folders from the folder where the driver package was stored and recreating the driver package from the original source files. We then update our TS to reference
the new driver package, redistribute the new package to all DP's. We are then able to successfully image our previously broken model.
So now the L440 works, but the x130e that just worked is now not working and if i go through the same steps to get it working, the L440 or another model might stop working.
i saw another suggestion about choosing the deployment option to "access content directly from a DP when needed" rather than "Download content locally when needed" when deploying the TS. The only option i have available is "Download
content locally...."
I have also verified the network adapter being used on the vm is vmxnet3. There were some other suggestions that this might cause an issue.
We have not upgraded to sp1 yet.
Any other suggestions?