Search the Community

We are running a single SCCM 2012 R2 SP1 CU1 server in out LAB environment with the following patches applied: https://support.microsoft.com/en-us/kb3091103/ https://support.microsoft.com/en-us/kb/3089193 https://support.microsoft.com/en-us/kb/3084586 We are LAB testing the Windows 10 deployment to our devices, including Surface Pro 3, Dell E5550, Dell E5530. Boot image is version WinPE 10.0.10240.16384 At this moment we are having issues with installing device drivers during deployment. Some drivers get installed without problems, but most of them won't install at all. Following is logged in smsts.log for every device that has a missing device driver: All drivers got installed successful in SCCM without errors, categorized and packages are created + deployed. Manually installing the drivers afterward using the same source files works without a problem and all drivers get installed perfectly so the drivers are correct. We have played around with setting "Best mached drivers" and "Limiting driver categories" for Auto Apply Drivers but to no result. The TS includes SMSTSDownloadRetryCount and SMSTSDownloadRetryDelay, without this the TS would error out. For testing we also tried Windows 7 deployment + drivers on the same server and that worked without problems and all drivers get installed. Anyone have any idea about this?

Hi all, Bit of a SSCM noob here, I'm an IT Manager (or IT GP) at a school with a deploymnent of about 800 clients. Since, I believe, I updated our site to CU1 (for SCCM 2012 R2) most of my clients have been stuck in some sort of install/repair loop. I have machines sitting in front of me, checking Task Manager I can see "CCM Insttallation Repair" and "ccmsetup.exe" both running for sometime, then once these clients are done and start getting policy I start seeing some notifications from the Software Centre for various programs etc before it all dissappears and starts the repair process again. I can't find anything useful in the logs (not 100% which logs to check in this instance but have been inspecting the ones most recently modified). Has anyone seen behaviour like this, how can I stop it without pulling every client in and manually uninstalling!? I have disabled Client-Push Installations (clientsd are usually installed as part of Task Sequence when we image machines) and any client upgrade deployments, not sure what to try next. Cheers

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?

Hello all, two quick questions: I've upgrade to CU1 (version 1202) and have two questions. 1. Console not showing the correctly installed version: I have only 45 devices that show in the console with version 5.00.7804.1202. I know that many more have this version and can confirm by looking on a given device and seeing the version in the control panel. Is there an action that will update this? 2. I have the right-click client install (push) still pushing 5.00.7804.1000 with the 1202 version coming in after as an update. How can I update the source for the push update accordingly? thanks!

Should I cut my losses and rebuild all my libraries? Some Background: Over the past week I have been trying to redistribute and validate all packages, applications and OSDs to our SCCM server. The reason for this is that one of the hdd for the server was relocated from one virtual datastore to another. Unfortunately we discovered after the fact that SCCM could no longer validate the hash of any of the packages - each and everyone was listed as unavailable. I set about redistributing them and validating them, but now I am faced with the situation that the process to validate\redistribute is hanging and not completing the job. Looking at the resource logs for the server I can see it is accessing the hdd at a high rate, but within tolerable limits. And aside from that, no other server resource is been unduly stressed or used. But at the same time, no packages, images, OSDs are getting validated or distributed. They all display "in progress". And have done so for several days now. And now for the complication that is the CU1 KB2817245 hotfix - this was unfortunately applied yesterday and we are unsure if it is the cause of the PXE not been able to distribute OSD TS or if that issue is tied to the "in progress" waiting. Leading me to either think I should cut my losses and to save time rebuild my entire catalogue. Or should I try and troubleshoot it some more...but then where should I start? Organisation info: We are a school with a single SCCM 2012 server in an 2008 R2 environment. All clients are managed with ConfigMngr. We make exclusive use of Windows 7 in a 40/60 split between x64 and x32 versions. Any info\help is appreciated.

The Cumulative Update 1 for System Center 2012 Configuration Manager Service Pack 1 KB2817245 has been released. http://support.microsoft.com/kb/2817245 contains the fixes, updates, and the request link for the hotfix which is approximately 59 MB.