Okidoki .after a fun day of doing builds and watching logs I found the issue . J
My TS has at the end a 2 min countdown reboot which is scripted to run outside the TS. While watching the smsts.log at the end of the build it does a lot of cleanup but got interrupted by the countdown reboot because it simply wasnt finished yet.. Apparently this had such an affect that it hosed up the client in such a way it couldnt get itself repaired. I remembered the introduced SP1 feature SMSTSPostAction, implemented that, did several rebuilds .et voila .much better now Thanks for the feedback .! From: [email protected] [mailto:[email protected]] On Behalf Of Matthias Berroth Sent: Thursday, November 21, 2013 10:06 AM To: [email protected] Subject: RE: [mssms] Client thingy after OSD build Do additional steps for the updates: - Install Updates (Continue on error) - Reboot - Install Updates(Continue on error) - Reboot - Install Updates(Continue on error) - Reboot From: [email protected] [mailto:[email protected]] On Behalf Of Craig Andrew (OIZ) Sent: Donnerstag, 21. November 2013 08:52 To: [email protected] Subject: AW: [mssms] Client thingy after OSD build Perhaps slightly off the original topic In my Test environment, someone (probably me), hadnt set up the update ADRs properly. After a couple of weeks I had far too many update deployments (cant remember but somewhere between 60 and 100) being deployed to the clients. This maxed out the available memory for the OSD TS (10Mb) and it wouldnt start. Removing old Update deployments fixed the problem. In this case it is the number of policies applied that causes the problem not the number of updates. But the number of updates is usually the cause of too many policies, if you get me. To keep an eye on policy processing check in the temp folder, C:\windows\ccm\temp and c:\Windows\CCM\CIDownloader\DigestStore You see here the amount of policy data the client is downloading and processing. If you have a huge amount of data in temp and the policyeval is running before this gets cleared down then you will eventually get a deadlock on the client. This means there are too many policies applied to the computer for the client to process in the eval interval. Von: [email protected] [mailto:[email protected]] Im Auftrag von David O'Brien Gesendet: Donnerstag, 21. November 2013 07:56 An: <mailto:[email protected]> [email protected] Betreff: RE: [mssms] Client thingy after OSD build I saw kind of the same at a customer who targeted (not necessarily installed) over 700 updates to the B&C collection which caused the Task sequence to fail. During the clean-up process we saw that at around 450 updates the TS started working again Mit freundlichen Grüßen / Best regards David OBrien Microsoft Enterprise Client Management MVP From: [email protected] [mailto:[email protected]] On Behalf Of Marcum, John Sent: 20 November 2013 23:22 To: [email protected] Subject: RE: [mssms] Client thingy after OSD build During the build and capture I had an issue because of too many patches. Called CSS and verified that it is a known issue. They had me inject the patches into the wim offline. (I didn't really like that since it's the default wim) _____ John Marcum Sr. Desktop Architect Bradley Arant Boult Cummings LLP _____ From: [email protected] [mailto:[email protected]] On Behalf Of Trevor Sullivan Sent: Wednesday, November 20, 2013 12:48 PM To: [email protected] Subject: RE: [mssms] Client thingy after OSD build Johan, Im not aware of there being any limit on the number of updates that can be deployed to a client I have never heard of such a thing. Have you considered updating your reference image, using a build & capture task sequence? Cheers, Trevor Sullivan From: [email protected] [mailto:[email protected]] On Behalf Of Johan van Dijk Sent: Wednesday, November 20, 2013 12:12 PM To: [email protected] Subject: [mssms] Client thingy after OSD build Not sure if someone had mentioned something similar couple of weeks ago .cant find it anymore K Is there any limit known regarding the amount of software updates you can advertise against a client ? After an OSD build it almost takes 30-45 minutes before ccmexec calms down and stops restarting itself and thus becomes usable ? Lots of activity regarding SUM entries within CIAgent.log passing by while this is occurring. I have a feeling that the number of patches being offered becomes a little too much .but not sure. Weird enough I only see this currently happening on an Optiplex 780 which is the oldest model we have Anyone a hunch where to look for ? _____ Confidentiality Notice: This e-mail is from a law firm and may be protected by the attorney-client or work product privileges. If you have received this message in error, please notify the sender by replying to this e-mail and then delete it from your computer. _____ Confidentiality Notice: This e-mail is from a law firm and may be protected by the attorney-client or work product privileges. If you have received this message in error, please notify the sender by replying to this e-mail and then delete it from your computer.
