Thanks Erik, I did the WSUS Cleanup Wizard. But I did not do the rest of what is in the link you sent. I will give that a shot.
Thanks you. Best Regards, Dave Landry Site Support Administrator Laird Technologies 1 Perimeter Road – Suite 700 Manchester, NH 03103 +1 603-935-7857 [Description: LairdLogo] From: [email protected] [mailto:[email protected]] On Behalf Of the codepoets Sent: Thursday, May 12, 2016 12:42 PM To: [email protected] Subject: Re: [MDT-OSD] Problem installing updates post install via MDT I would second that this is probably a WSUS issue. It sounds like you're seeing WSUS issues across the board, and you've verified the taking WSUS out of the loop resolves the issues. It might be beneficial to look at the following and take this in as a WSUS issue... https://blogs.technet.microsoft.com/configurationmgr/2016/01/26/the-complete-guide-to-microsoft-wsus-and-configuration-manager-sup-maintenance/ I was able to resolve a lot of issues we had crop up with WSUS a few months ago by doing the maintenance in that blog post. -erik On Thu, May 12, 2016 at 8:22 AM, Keith Garner (Hotmail) <[email protected]<mailto:[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<tel:%28-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]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of David Landry Sent: Thursday, May 12, 2016 6:23 AM To: [email protected]<mailto:[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
