When that happens just add a few more steps, or better yet decrease the number of updates you have deployed to that collection the system is in.
On Thu, May 12, 2016 at 10:22 AM, Keith Garner (Hotmail) < [email protected]> wrote: > First off, the logs don’t match here. Hard to debug. > > > > ZTIWindowsUpdate.log has a query between > > > > Start Search... ZTIWindowsUpdate 4/28/2016 12:04:31 PM 0 (0x0000) > > Timeout Error WU_E_PT_EXCEEDED_MAX_SERVER_TRIPS : Retry! > (-2145107952) ZTIWindowsUpdate 4/28/2016 > 12:06:03 PM 0 (0x0000) > > > > However I WIndowsUpdate2.log and WindowsUpdate3.log appear to be outside > of the ZTIWindowsUpdate.log in time stamp. > > > > A quick glance at the other logs don’t reveal anything. > > > > I’m not a WSUS expert by any means, but my first thoughts are that you > might have some kind of server corruption. > > > > -k > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *David Landry > *Sent:* Thursday, May 12, 2016 6:23 AM > *To:* [email protected] > *Subject:* [MDT-OSD] Problem installing updates post install via MDT > > > > Hi All, > > > > I have run into a brick wall. For 2 years now, our Windows 7 images (we > only use Windows 7) updates via MDT installed updates on the first pass. > What we have been seeing for the last 2-3 weeks is: > > > > - First pass searches for update and reboots within 2 mins and > does not install any updates. > > - Second pass searches for update and reboots within 4 mins and > does not install any updates. > > - The third, fourth, fifth, and sixth passes searches and just > hangs there before reboots and does not install any updates. > > - The Seventh pass installs about 40 updates. > > - The 8th pass searches for about 2 ½ hours and does not install > any updates. > > - I have installed Windows6.1-KB3138612-x64.msu, > Windows6.1-KB3112343-x64.msu, Windows6.1-KB3102810-x64.msu into new test > images based on articles I have read on the internet. But these have not > helped the problem. > > - I’ve tested a new wim that had the contents of > C:\Windows\SoftwareDistribution cleaned out. That didn’t help. > > - I thought about updating to Update 2 but didn’t see anything > that would potentially help aside from better logging for the smsts.log > file. > > - I have looked at most of the errors in the logs. But have not > found a resolution that works. > > - I have included some logs from the testing I have been doing. > > > > - *If I bypass the WSUS server and go directly to Microsoft for > updates via MDT, updates start installing on the first pass*. > > - *I created a new image with all the updates in it and that did > not error out, but instead reported back there were no updates available*. > > > > WU client versions during testing: 7.6.7601.19016 > > > 7.6.7601.19077 > > > 7.6.7601.19161 > > > > MDT 2013 update 1 version: 6.3.8298.1000 > > > > The entire process, imaging, drivers, all applications, and all updates > used to take about 2 hours to complete. Now due to the update problem, it > is taking 6+ hours per machine. > > > > This is not just happening on my local MDT server, but from what I am > hearing, it is occurring on all MDT servers corporate wide. > > > > At this point I am leaning to either a WSUS problem of some kind such as > Client version issue or a bad update as the culprit. > > > > Anyone seen this before? Any ideas? > > > > Best Regards, > > > > Dave Landry > > > > > > >
