jimbojones444

thanks for the responses Peter and VRDRF. We ended up deleting all but the two latest packages last week. However these packages have now seemed to regenerate - bringing the total no of packages of this type to 14, as can be seen in the image below: (also note that the package source is the same) I understand that SCCM automatically recreates the primary client package if it is accidently deleted. Could it be automatically creating these packages as well? thanks!

Hi peter, thanks for the reply. We have now deleted all but one of both of these packages. Do you know if these packages should only reside in this top-level "Packages" folder in the software library? If we were to move one to a subfolder, will SCCM detect this after 4 hours and then regenerate it? cheers!

Earlier this year we upgraded from "SCCM2012 RTM CU3" to "SCCM2012 R2CU1" We've noticed that we now have 3x "Configuration Manager Client Upgrade Package" and 3x "Configuration Manager Client Package" packages sitting directly under the top-level "Packages" folder in the software library. [see attached screenshot1.PNG] Two of the upgrade packages have deployments linked to the "All Systems" collection. We have used the Client Center tool to check the execution history on several machines, and they install both of the linked upgrade packages... So I guess the questions I have are: Why do we have so many of these packages? and which can we safely delete? cheers!

thanks guys for your tipps! i actually managed to figure out why it was failing for some boot.wim's but not others. it was because my test VM only had 512mb of memory assigned... oops it seems that the x86 boot.wim does not consume enough memory to cause a crash, but the x64 does - that is why the x86 one would progress a lot further into the TS...

Hi There, We recently upgraded from SP1CU3 -> R2CU1 and are now having issues building machines using our OSD task sequence. First we tried using our existing x64 boot.wim (version 6.2.9200) - however our task sequence fails at the diskpart stage. We then noticed that the driver tab is missing from the Boot Images properties page - probably because the WIM was created by an older version of ADK. So then we tried using the boot image automatically placed into SCCM by the ADK8.1 install (6.3.9600.16384) in our task sequence. However this results in a WIndows8 BSOD screen with the error message "BAD_SYSTEM_CONFIG_INFO" after it finishes downloading the WIM file and shows the windows logo briefly (but before getting to the familiar WinPE page). Finally we tried using a freshly baked boot.wim created with the "copype.cmd amd64" command. Using this boot.wim in our task sequences allows the build process to progress a little further - we see it initialise WinPE and go through a couple of status messages before hard rebooting. The last status message it shows before it reboots the machine is "Preparing network connections...". NB: we were able to progress much further into our task sequence using the x86 ADT8.1 boot image... Any ideas on what we can try next?