Windows server 2012 r2 wsus видит win10 как vista

Wsus видит windows 10 как vista

Вопрос

We have been using Windows 2008 R2 server for our WSUS server. It’s been doing a good job, but when Windows 10 came along, WSUS flag it as Windows Vista. Any idea why WSUS flag Windows 10 as Vista?

Ответы

>>Any idea why WSUS flag Windows 10 as Vista?

Microsoft has released a hot fix for this issue:

Steven Lee Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

Server 2008 R2 is no longer a feature supported platform, because it’s in extended mode, it will never get this hotfix.

Am 02.09.2015 schrieb MaxxamA:

We have been using Windows 2008 R2 server for our WSUS server. It’s been doing a good job, but when Windows 10 came along, WSUS flag it as Windows Vista. Any idea why WSUS flag Windows 10 as Vista?

Check the Build from your WSUS:

WSUS 3.0 (SP2): Build 3.2.7600.226
WSUS 3.0 (SP2) + KB2720211: Build 3.2.7600.251
WSUS 3.0 (SP2) + KB2734608: Build 3.2.7600.256
WSUS 3.0 (SP2) + KB2828185: Build 3.2.7600.262
WSUS 3.0 (SP2) + KB2938066: Build 3.2.7600.274

Источник

Как исправить ошибку 0x8024401 при обновлении Windows 10 со WSUS

У одного из заказчиков столкнулись с проблемой обновлений новых ПК с Windows 10 1607 и Windows Server 2016 с внутреннего WSUS сервера (на Windows Server 2012 R2). Компьютеры Windows 10 появляются в консоли WSUS, но при запуске поиска обновлений, клиент очень долго пытается их найти и возвращает ошибку 0x8024401c.

There were some problems installing updates, but we’ll try again later. If you keep seeing this and want to search the web or contact support for information, this may help: (0x8024401c)

Согласно списка кодов ошибок центра обновления Windows ошибка 0x8024401C означает превышение таймаута ответа от клиента: WU_E_PT_HTTP_STATUS_REQUEST_TIMEOUT — HTTP status 408 — the server timed out waiting for the request.

В новом журнале логов службы Windows Update Windows 10 при этом также периодически фиксируется ошибка, связанная с таймаутом ответа WSUS.

2017-05-30 14:11:24:870 816 1244 WS WARNING: There was an error communicating with the endpoint at ‘http://msk-wsus:8530/ClientWebService/client.asmx’.
2017-05-30 14:11:24:870 816 1244 WS WARNING: There was an error receiving the HTTP reply.
2017-05-30 14:11:24:870 816 1244 WS WARNING: The operation did not complete within the time allotted.
2017-05-30 14:11:24:870 816 1244 WS WARNING: The operation timed out

Сама страница ‘http://msk-wsus:8530/ClientWebService/client.asmx‘ при этом с клиента доступна и открывается, т.е. возникает такое ощущение, что сервер WSUS или клиент просто не успевают выполнить некую операцию и клиент отваливается по таймауту. Возможно при инициирующем сканировании, новому клиенту WSUS прилетает слишком большой список обновлений, в результате чего достигаются некие лимиты рабочего процесса IIS.

Чтобы решить проблему с клиентами, мне пришлось сначала установить на сервере WSUS обновление KB3159706 (на сервере должен быть установлен Wndows Server 2012 R2 Update 1 ).

В статье KB3159706 (Update enables ESD decryption provision in WSUS in Windows Server 2012 and Windows Server 2012 R2) обратите внимание на ручные действия, которые нужно выполнить после установки обновления (иначе может перестать открываться консоль WSUS).

Источник

Эффект Dual Scan в Windows 10 и проблемы обновления со WSUS

Лично для меня было открытием, что в некоторых случаях компьютеры с Wiindows 10 могут не получать обновления со внутреннего WSUS сервера, вместо этого обращаясь в Интернет к серверам обновления Microsoft, хотя WSUS сервер для клиентов жестко установлен стандартной групповой политикой. Данная проблема связан с термином Dual Scan (не встречал на русском расшифровку термина, пусть это будет двойное сканирование).

Понятие Dual Scan представляет собой такую комбинацию настроек в Windows 10 1607 и выше, при которой клиенты начинают игнорировать настройки локального WSUS сервера, параллельно обращаясь для сканирования на наличие новых обновлений на внешние сервера Windows Update. Первые обращения с подобными проблемами были еще в мае 2017 года.

Сканирование обновлений выполняется одновременно и на WSUS сервере и на серверах WU, однако клиент принимает апдейты только от серверов WU. Таким образом, все обновления/патчи с локального WSUS, относящиеся к категории Windows будут игнорироваться такими клиентами. Т.е. обновления Windows в таком режиме получаются из интернета, а обновления драйверов и других продуктов со WSUS.

В моем случае на проблемном клиенте, в разделе Computer ConfigurationAdministrative TemplatesWindows ComponentsWindows Update были включены две стандартные политики для обновления ПК со внутреннего WSUS:

• Configure Automatic Updates
• Specify intranet Microsoft update service location

При этом на клиентских ПК Windows 10 в панели управления в разделе Обновления и безопасность –> Центр обновления Windows -> Дополнительные параметры включена опция Отложить получение обновлений компонентов (настройка аналогична политике ‘Select when Feature Updates are received’)

При такой комбинации настроек клиенты перестают получать обновления Windows со внутреннего WSUS сервера.

Таким образом, ситуация Dual Scan возникает при следующих комбинациях политик (или эквивалентных ключей реестра или настроек на клиентах Windows 10):

• Задан адрес локального WSUS политикой Specify intranet Microsoft update service location
• Включена одна из политик, относящихся к возможности отложенной установки апдейтов в концепции Windows Update for Business:
  • Select when Feature Updates are received
  • Select when Quality Updates are received

Чтобы исключить ситуацию с Dual Scan, а клиенты выполняли поиск обновлений Windows только на внутреннем WSUS сервере, нужно включить политику Do not allow update deferral policies to cause scans against Windows Update в разделе Computer ConfigurationAdministrative TemplatesWindows ComponentsWindows Update.

Данная политика присутствует в Windows 10 1607, однако в Windows 10 версии 1703 ее по умолчанию нет. Чтобы данная настройка GPO появилась, нужно установить обновление KB4034658 от 8 августа 2017.

Источник