Tefty

After further testing 8 more units of the same model and exhibiting successful builds I decided to attack the hard drives, turns out its faulty drives on long reads...

Thanks Anyweb, long time fan and avid follower! Was thanks to your site I got into SCCM and certified back in 2012 release. I will give the PowerCFG a try tomorrow along with injecting some storage drivers and BIOS update. I don't understand why its just happened and the logs are little use.

BUMP - Anyone with any ideas on this one? Just created 2 new boot images both x86 and x64 from a fresh Windows ADK 10 install and still have the same issue. The fact that is used to work fine still has me completely baffled on this. Will try injecting some Storage drivers tomorrow into the boot image to see if that will make any difference at all but the only relevant driver I can find is the Intel Rapid Storage driver which i can't see working.

Morning all, Throwing this one out there to any SCCM peeps as this is one issue I have not seen before (and I thought I had seen them all). Have a Lenovo M73 Tiny PC which has been building fine through our environment for 2 years up to about 5 weeks ago (no major changes on a system level). During the WIM download/install phase I am seeing a MASSIVE delay of about an hour straight after the download of the WIM to when it should then go straight into Applying the WIM. Anyone seen this before? All other machines and Images are fine so cant be a server issue, any image that's applied to this model of machine now has this hour long pause/hang. I have attached a portion of the log staring out the server name for security and have spaced out the middle section of interest. SCCM_Delay_Build.txt

Here's the fix:- https://social.technet.microsoft.com/Forums/windows/en-US/7109081b-a82a-46e4-b6fe-f19b7d56e431/problem-with-some-msi-installs-after-kb3139923?forum=w7itproinstall Its not SCCM itself thats the issue or the client its a bl**dy Windows patch. I had KB3139923 serviced into my Windows images as I do with all new updates but it breaks the Windows installer process unless KB3072630 is installed with it. In short - I downloaded the update, inserted into my images and deployed to all live machines.

Aye worked that one out as well 10 minutes after posting... Between this and the new "Error 1406. Could not write value LastMsgSerialNum to key \SOFTWARE\Microsoft\CCM\StateSystem. System error . Verify that you have sufficient access to that key, or contact your support personnel." my current new builds are doing fantastically well !

Chiming in to say I also have this issue, what more annoying is its happening during my PC task sequences and therefore I end up with a useless machines due to no apps being installed.

So its not just me that has this issue then, thought I was going completely mad for a minute... So this could be an inherit issue with SCCM 1602 ?

I was doing some SCEP work this morning and noticed a few of my machines were running the 4.9.219.0 Antimalware Client Version while others were running 4.7.214.0. Having then dug through my ADR definition deployment rules I can see that the packages being created and deployed have the newer version so was a little confused as to why some had not updated which I have still yet to get to the bottom of. In the meantime I noticed that the client directory in the SMS_Site directory has an updated with the latest CCMSetup.exe from my 1602 upgrade which is great but the SCEPinstall.exe is showing the old 4.7.214.0 version. I know the 2 are differently managed however the site server itself is running the 4.9.219.0 and as far as I was aware when the site server updates it was supposed to update the SCEPInstall.exe in the client directory so the latest SCEPInstall gets installed by default with the SCCM client. I've dug through the updates and found the latest SCEPInstall.exe package so will replace manually but has anyone else seen this or have any advice on how to proceed with this? Thanks, Andy

Well it would appear my old SCCM 2007 server does exactly the same... I've just never noticed... The OSD is going out at the same rates as the new one and BITS doesn't seem to be taking any affect.

Having just spent a few hours reading through some technet docs i've still not found an answer to this other than enabling multicast however this would not work due to the image being installed direct from the DP instead of being deployed and then installed. I've either had a really really long day and am completely missing a point here or OSD throttling has vanished. Luckily I still have my old SCCM 2007 hanging around (turned off). May have to break it out and do a bandwidth comparison when doing an OSD of this nature from each as the image has not changed from when I migrated it over.

Can't see of anything wrong then with your setup... Sorry!

Are you using the WIM direct from a Windows 7 fresh image and not from a previous custom made image?

Afternoon all, I'm having an issue with my OSD on SCCM 2012 SP1 where I have a Windows Embedded Image setup for deployment to HP Thin Clients. The TS and all associated Applications are being installed via the Deployment Option "Access contect directly from distribution" due to the Thin Clients only having 4GB of Flash Memory. This all works fine in terms of image etc... except for not being able to get the EWF to apply automatically at the end of the build process, even using the new SMSTSPostAction TS Variable to run the command line but ho hum... My issue with the OSD is that its installing the image from the server and chucking it out at anything from 70 to 90 MB sec!!! which in turn is killing my poor fibre backbone when more than 3 or 4 machines are on the go at the same time. In SCCM 2007 there was the BITS setting which specifically stated "OSD throttling through BITS". In SCCM 2012 the BITS options are now in client settings with no sign of any OSD BITS throttling?!?! Am I going mad or is there an answer to this as I can only build 1 of these at a time now whereas with SCCM 2007 I could slap off 5+ on the go... Andy