Наладзіць проксі сінхранізацыі WSUS
Наладзьце ўліковыя даныя і канчатковы пункт сінхранізацыі WSUS у яго ўласнай кансолі, а не спадзявайцеся на браўзер адміністратара і не лічыце гэту наладу кліенцкай палітыкай.
На існуючым серверы WSUS наладзьце проксі для сінхранізацыі ў самім WSUS. Сеанс браўзера пад уліковым запісам адміністратара не даказвае, што служба сінхранізацыі мае той жа маршрут або тыя ж уліковыя даныя.
У кансолі адміністравання WSUS адкрыйце Параметры, затым Крыніца абнаўленняў і проксі-сервер. На ўкладцы проксі ўключыце выкарыстанне проксі для сінхранізацыі і ўкажыце імя сервера і порт праслухоўвання; калі тэст Microsoft Update дапускае публічныя проксі і не мае наладжаных уліковых даных проксі, выберыце HTTP-кандыдата са спісу HTTP-проксі.
Калі гэты проксі патрабуе пэўнага ўліковага запісу, увядзіце карыстальніка, дамен і пароль у палях уліковых даных WSUS. Поле дамена павінна адлюстроўваць схему ўліковых запісаў, якую падаў адміністратар проксі; яно не абавязкова з'яўляецца публічным суфіксам DNS імя хоста проксі.
Microsoft дакументуе гэтую наладу як такую, што датычыцца сінхранізацый WSUS, уключаючы сінхранізацыю з вышэйшым серверам WSUS або з Microsoft Update. Яна не наладжвае браўзер кожнага ніжэйшага камп'ютара і не наладжвае злучэнне Windows Update.
Кансоль таксама прапануе Basic-аўтэнтыфікацыю ў яўным выглядзе. Разглядайце яе як выбар аўтэнтыфікацыі, а не як універсальны сцяжок, што робіць уваход працоўным: Microsoft папярэджвае, што пры гэтым механізме пароль перадаецца без шыфравання.
Калі сінхранізацыя ўсё яшчэ не ўдаецца, запішыце наладжаную крыніцу абнаўленняў і этап збою. Недасяжны праслухоўвальнік проксі, адхіленне аўтэнтыфікацыі проксі і збой пасля дасягнення вышэйшай службы патрабуюць розных выпраўленняў. Паўторны ўвод працоўнага пароля браўзера мала што значыць, пакуль WSUS не выкарыстоўвае чаканы ўліковы запіс проксі.