http://mnscug.org/blogs/sherry-kissinger/360-wsus-sup-servers-in-configmgr-2012-custom-configuration-settings
http://mnscug.org/blogs/brian-mason/361-how-to-melt-a-sup
http://blog.coretech.dk/kea/house-of-cardsthe-configmgr-software-update-point-and-wsus/
Basically, read through those. But essentially what you want to check is how
much memory have you allowed your WSUS AppPool to have? it may be failing
there. Also, you don't mention it; but is your SUP on the same server as your
primary? i.e., your one single server does it all? that might be fine--if
there's enough memory for WSUS and SQL and ConfigMgr to all be happy together.
But if you aren't limiting what SQL can have, and you aren't giving WSUS
enough--but yet STILL leaving enough left over for ConfigMgr itself to be
happy... you might either simply need more memory, or need to tweak how much
memory you let sql and the wsus app pool have.
On Monday, November 30, 2015 8:33 AM, Charles Hiland
<[email protected]> wrote:
<!--#yiv0611296102 p {margin-top:0px;margin-bottom:0px;}-->A few months ago
we began using SCCM's SUP feature to patch workstations. We started with 45 or
so machines, then moved up to 150, then to about 250. Everything appeared to be
working correctly, so we released it company-wide.Of course we would run into
an issue. The WUHandler.log file is giving me 0x80072EE2 which is
ERROR_INTERNET_TIMEOUTIt only seems to work in the early AM and late PM hours
when staff aren't at work. For $500.00, a MS tech connected and tried to help
resolve the issue. We pruned the WSUS database to remove over 3500
expired/unused updates over the holiday weekend, and machines slowly appeared
to be getting the updates downloaded, but everyone has returned to work today
and we are back to the timeout errors.Any advice? We only have one primary
server, no CAS, and things were working before we unloaded 1500 more users onto
the system.Thanks in advance.
