Windows 10 в домене не обновляется

Содержание

• Способ 1: Сброс настроек в твикерах
• Способ 2: Проверка политики автообновления
• Способ 3: Проверка службы обновления
• Способ 4: Проверка реестра
• Способ 5: Откат к точке восстановления
• Вопросы и ответы

Причиной появления этого сообщения является изменение некоторых настроек Windows 10, в частности, связанных с обновлениями и безопасностью. Причем изменения эти могли быть внесены как непосредственно администратором, так и с помощью специальных программ-твикеров.

Способ 1: Сброс настроек в твикерах

В Windows 10 программы-твикеры обычно применяются для тонкой настройки операционной системы, а также для отключения следящих функций. Пользоваться такими инструментами нужно с осторожностью, в противном случае можно нарушить работу компонентов системы. Если вы использовали подобные утилиты, восстановите измененные ими настройки — благо, большинство твикеров позволяют отменять изменения. Например, в популярном твикере OOSU10 для этого нужно выбрать опцию «Отменить все изменения» на одноименной вкладке.

Способ 2: Проверка политики автообновления

Уведомление «Ваша организация отключила автоматические обновления» появится, если пользователь или администратор отключил автоматическое обновление системы в локальных групповых политиках.

1. Откройте нажатием Win + R окошко быстрого выполнения команд, введите в него команду gpedit.msc и нажмите клавишу ввода.



2. Запустится «Редактор локальных групповых политик». Перейдите в нем по цепочке «Конфигурация компьютера» → «Административные шаблоны» → «Компоненты Windows» → «Центр обновления Windows» и отыщите в правой колонке политику «Настройка автоматического обновления».



3. Если политика имеет статус «Включена», откройте двойным кликом ее свойства и выставьте для нее значение «Не задана» или «Отключена».

Сохраните настройки и перезагрузите компьютер.

Способ 3: Проверка службы обновления

Проверьте состояние службы, отвечающей за получение обновлений Windows. Она должна быть активной.

1. Откройте оснастку управления службами, для чего в диалоговом окошке Win + R выполните команду services.msc.



2. Отыщите в списке служб службу «Центр обновления Windows» и убедитесь, что она выполняется и имеет тип запуска «Автоматически» или «Вручную».



3. В противном случае откройте «Свойства» службы двойным кликом и попробуйте ее запустить нажатием одноименной кнопки, изменив тип запуска на «Автоматически» или «Вручную».



4. Аналогичным образом найдите в списке службу «Фоновая интеллектуальная служба передачи (BITS)» и запустите ее, если не запущена. Тип запуска этой службы выставьте «Автоматически».

Способ 4: Проверка реестра

Для отключения автоматического обновления администраторы нередко применяют твик реестра. Проверьте указанный ниже ключ на предмет внесенных в него изменений.

1. Откройте «Редактор реестра» командой regedit в диалоговом окошке «Выполнить», вызванном нажатием комбинации клавиш Win + R.



2. Разверните в левой колонке ключ HKLMSOFTWAREPoliciesMicrosoftWindowsWindowsUpdateAU и удалите из последнего подраздела все параметры. Это восстановит настройки обновления по умолчанию.





3. Перезагрузите компьютер.

Способ 5: Откат к точке восстановления

Если вы не нашли подходящего решения, выполните откат Windows 10 к ближайшей точке восстановления. Эта операция восстанавливает некоторые системные файлы и реестр, а вместе с ним и измененные настройки, которые могли привести к появлению уведомления «Ваша организация отключила автоматические обновления».

Подробнее: Откат к точке восстановления в Windows 10

Еще статьи по данной теме:

Помогла ли Вам статья?

Как получать обновления windows 10 в обход домена?

На работе комп (win 10 corp/pro) введен в домен. Доменные настройки и обновления винды есть только для XP и win7. Соответственно win10 тоже настроился на локальный wsus, на котором для него ничего нет. Как можно (через реестр или как) указать системе обычные сервера обновлений через инет, а не локальные, не выводя из домена?
Переделать доменные настройки не предлагать 🙂

p.s. почему то просьба НЕ предлагать переделать настройки домена никого не волнует. я НЕ администратор данного домена, он находиться в другом городе и администрируется другими людьми (я лишь нахожусь в небольшом филиале и не имею к нему ни малейшего доступа). у нас официально не используется win 10 в работе и поэтому у нас и НЕ БУДЕТ в ближайшее время изменений в wsus. это не моя прихоть! я лишь сам интересуюсь десяткой и работаю на ней, так как сам по себе домен и большинство настроек он нормально принимает как и win 7

wsus, на котором для него ничего нет.

Сообщите об этом администратору WSUS. Необходимо включить соответствующую категорию обновлений для синхронизации.

Или скачивать их Каталог Центра обновления Майкрософт. Поскольку для Windows 10 выпускается одно кумулятивное обновление в месяц (редко, обновление безопасности, отдельно — но входящее в следующее кумулятивное) это не доставит больших хлопот.
Журнал обновлений Windows 10

А ведь сразу даже в голову не пришло:

указать системе обычные сервера обновлений через инет, а не локальные

Источник

Установка и настройка сервера обновлений WSUS

Windows Server Update Services или WSUS предназначен для распространения обновлений внутри сети. Он позволит скачивать все пакеты для их установки на один сервер и распространять данные пакеты по локальной сети. Это ускорит процесс получения самих обновлений, а также даст администратору контроль над процессом их установки.

В данной инструкции мы рассмотрим пример установки и настройки WSUS на Windows Server 2012 R2.

Перед установкой

Рекомендуется выполнить следующие действия, прежде чем начать установку WSUS:

Также нужно убедиться, что на сервере достаточно дискового пространства. Под WSUS нужно много места — в среднем, за 2 года использования, может быть израсходовано около 1 Тб. Хотя, это все условно и, во многом, зависит от количества программных продуктов, которые нужно обновлять и как часто выполнять чистку сервера от устаревших данных.

Установка роли

Установка WSUS устанавливается как роль Windows Server. Для начала запускаем Диспетчер серверов:

На странице приветствия просто нажимаем Далее (также можно установить галочку Пропускать эту страницу по умолчанию):

На следующей странице оставляем переключатель в положении Установка ролей или компонентов:

Далее выбираем сервер из списка, на который будем ставить WSUS:

Среди компонентов оставляем все по умолчанию и нажимаем Далее:

Мастер запустит предварительную настройку служб обновления — нажимаем Далее:

Среди ролей службы можно оставить галочки, выставленные по умолчанию:

Прописываем путь, где WSUS будет хранить файлы обновлений:

* в нашем примере был прописан путь C:WSUS Updates. Обновления нужно хранить на разделе с достаточным объемом памяти.

Запустится настройка роли IIS — просто нажимаем Далее:

Среди служб ролей оставляем все галочки по умолчанию и нажимаем Далее:

В последнем окне проверяем сводную информацию о всех компонентах, которые будут установлены на сервер и нажимаем Установить:

Процесс установки занимаем несколько минут. После завершения можно закрыть окно:

Установка роли WSUS завершена.

Первый запуск и настройка WSUS

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

При первом запуске запустится мастер завершения установки. В нем нужно подтвердить путь, по которому мы хотим хранить файлы обновлений. Кликаем по Выполнить:

. и ждем завершения настройки:

Откроется стартовое окно мастера настройки WSUS — идем далее:

На следующей странице нажимаем Далее (при желании, можно принять участие в улучшении качества продуктов Microsoft):

Далее настраиваем источник обновлений для нашего сервера. Это может быть центр обновлений Microsoft или другой наш WSUS, установленный ранее:

* в нашем примере установка будет выполняться из центра Microsoft. На данном этапе можно сделать сервер подчиненным, синхронизируя обновления с другим WSUS.

Если в нашей сети используется прокси-сервер, задаем настройки:

* в нашем примере прокси-сервер не используется.

Для первичной настройки WSUS должен проверить подключение к серверу обновлений. Также будет загружен список актуальных обновлений. Нажимаем Начать подключение:

. и дожидаемся окончания процесса:

Выбираем языки программных продуктов, для которых будут скачиваться обновления:

Внимательно проходим по списку программных продуктов Microsoft и выбираем те, которые есть в нашей сети, и для который мы хотим устанавливать обновления:

* не стоит выбирать все программные продукты, так как на сервере может не хватить дискового пространства.

Выбираем классы обновлений, которые мы будем устанавливать на компьютеры:

* стоит воздержаться от установки обновлений, которые могут нанести вред, например, драйверы устройств в корпоративной среде не должны постоянно обновляться — желательно, чтобы данный процесс контролировался администратором.

Настраиваем синхронизацию обновлений. Желательно, чтобы она выполнялась в автоматическом режиме:

Мы завершили первичную настройку WSUS. При желании, можно установить галочку Запустить первоначальную синхронизацию:

После откроется консоль управления WSUS.

Завершение настройки сервера обновлений

Наш сервис установлен, настроен и запущен. Осталось несколько штрихов.

Установка Microsoft Report Viewer

Для просмотра отчетов, необходим компонент, который не ставится с WSUS. Для его установки нужно сначала зайти в установку ролей и компонентов:

Продолжаем установку и завершаем ее.

Для загрузки Microsoft Report Viewer переходим на страницу https://www.microsoft.com/en-us/download/details.aspx?id=3841 и скачиваем установочный пакет:

После выполняем установку приложения и перезапускаем консоль WSUS — отчеты будут доступны для просмотра.

Донастройка WSUS

Мастер установки предлагает выполнить большую часть настроек, но для полноценной работы необходимо несколько штрихов.

1. Группы компьютеров

При подключении новых компьютеров к серверу, они должны распределиться по группам. Группы позволят применять разные обновления к разным клиентам.

Вводим название для группы и повторяем действия для создания новой группы. В итоге получаем несколько групп, например:

2. Автоматические утверждения

После получения сервером обновлений, они не будут устанавливаться, пока системный администратор их не утвердит для установки. Чтобы не заниматься данной работой в ручном режиме, создадим правила утверждения обновлений.

Кликаем по Создать правило:

У нас есть возможность комбинировать условия, при которых будут работать наши правила. Например, для созданных ранее групп компьютеров можно создать такие правила:

3. Добавление компьютеров в группы

Ранее, нами были созданы группы компьютеров. После данные группы использовались для настройки автоматического утверждения обновлений. Для автоматизации работы сервера осталось определить, как клиентские компьютеры будут добавляться в группы.

Если мы хотим автоматизировать добавление компьютеров в группы, необходимо установить переключатель в положение Использовать на компьютерах групповую политику или параметры реестра:

Настройка клиентов

И так, наш сервер готов к работе. Клиентские компьютеры могут быть настроены в автоматическом режиме с помощью групповой политики Active Directory или вручную в реестре. Рассмотрим оба варианта. Также стоит отметить, что, как правило, проблем совместимости нет — WSUS сервер на Windows Server 2012 без проблем принимает запросы как от Windows 7, так и Windows 10. Приведенные ниже примеры настроек являются универсальными.

Групповая политика (GPO)

Открываем инструмент настройки групповой политики, создаем новые политики для разных групп компьютеров — в нашем примере:

Название политики	Значение	Описание
Разрешить управлению электропитанием центра обновления Windows выводить систему из спящего режима для установки запланированных обновлений	Включить	Позволяет центру обновления выводить компьютер из спящего режима для установки обновлений.
Настройка автоматического обновления	Включить. Необходимо выбрать вариант установки, например, автоматическую. Также задаем день недели и время установки. Для серверов рекомендуется не устанавливать обновления автоматически, чтобы избежать перезагрузок.	Позволяет определить, что нужно делать с обновлениями, как именно их ставить и когда. Обратите внимание, что Microsoft большую часть обновлений выпускает во вторник — используйте эту информацию, чтобы задать наиболее оптимальное время установки.
Указать размещение службы обновлений Microsoft в интрасети	Включить. Указать адрес сервера в формате веб ссылки, например, http://WSUS-SRV:8530 *	Настройка говорит клиентам, на каком сервере искать обновления.
Разрешать пользователям, не являющимся администраторами получать уведомления об обновлениях	Включить	Позволяет предоставить информацию об устанавливаемых обновлениях всем пользователям.
Не выполнять автоматическую перезагрузку, если в системе работают пользователи	Включить	Позволит избежать ненужных перезагрузок компьютера во время работы пользователя.
Повторный запрос для перезагрузки при запланированных установках	Включить и выставить значение в минутах, например, 1440	Если перезагрузка была отложена, необходимо повторить запрос.
Задержка перезагрузки при запланированных установках	Включить и выставить значение в минутах, например, 30	Дает время перед перезагрузкой компьютера после установки обновлений.
Разрешить клиенту присоединяться к целевой группе	Включить и задать значение созданной в WSUS группе компьютеров: — Рабочие станции — Серверы — Тестовая группа	Позволяет добавить наши компьютеры в соответствующую группу WSUS.

* 8530 — сетевой порт, на котором по умолчанию слушает сервер WSUS. Уточнить его можно на стартовой странице консоли управления WSUS.

Ждем применения политик. Для ускорения процесса некоторые компьютеры можно перезагрузить вручную.

Настройка клиентов через реестр Windows

Как говорилось выше, мы можем вручную настроить компьютер на подключение к серверу обновлений WSUS.

Для этого запускаем редактор реестра и переходим по пути: HKEY_LOCAL_MACHINESOFTWAREPolicesMicrosoftWindowsWindowsUpdate. Нам необходимо создать следующие ключи:

Теперь переходим в раздел реестра HKEY_LOCAL_MACHINESOFTWAREPolicesMicrosoftWindowsWindowsUpdateAU. Если он отсутствует, создаем вручную. После нужно создать ключи:

После перезагружаем компьютер. Чтобы форсировать запрос к серверу обновлений, на клиенте выполняем команду:

Автоматическая чистка WSUS

Как говорилось ранее, сервер WSUS очень требователен к дисковому пространству. Поэтому удаление устаревшей информации является критически важным этапом его администрирования.

Также можно воспользоваться командлетом в Powershell Invoke-WsusServerCleanup — целиком команда будет такой:

Источник

Настройка автоматического обновления компьютеров в рабочих группах

Для обеспечения безопасности и поддержания актуального состояния операционной системы очень важно регулярно загружать и устанавливать последние обновления. Обновление может выполняться как каждым клиентским компьютером с сайта Microsoft Update, так и централизованно, посредством использования сервера Windows Server Update Services (WSUS).

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

Наилучшим способом настройки автоматического обновления является использование групповых политик, однако это возможно только в случае, если в организации есть служба каталогов Active Directory. Если же AD в организации не развернута и компьютеры находятся в рабочих группах, то доменные групповые политики отпадают и настроить клиента на использование WSUS можно либо посредством локальной групповой политики, либо путем прямого внесения изменений в системный реестр компьютера.

Предварительная настройка

Сначала нам необходимо произвести некоторые настройки на сервере WSUS. Открываем консоль управления WSUS и в разделе «Computers» создаем новую группу, в которую будут входить наши компьютеры. Назовем ее Workgroup.

Создав группу идем на вкладку «Options» и там, в разделе «Computers» указываем серверу WSUS размещать компьютеры в группах согласно групповым политикам или настройкам реестра. В противном случае все новые компьютеры автоматически попадают в группу Unassigned Computers.

Групповая политика

Теперь можно приступать к настройке клиента. Заходим на клиентский компьютер, нажимаем Win+R и набираем команду gpedit.msc. Открывается редактор локальной политики компьютера. За настройку обновлений отвечает раздел Конфигурация компьютера — Административные шаблоны — Компоненты Windows — Центр обновления Windows.

Нам надо настроить следующие политики:

Указать размещение службы обновлений Microsoft в интрасети — задаем адрес или имя сервера обновлений, к которому будет выполняться подключение клиента, а также адрес сервера статистики. Можно указать один и тот же адрес для обеих задач.

Разрешить клиенту присоединение к целевой группе — указываем имя группы на сервере WSUS, к которой должен быть присоединен данный компьютер. В нашем случае это Workgroup.

Настройка автоматического обновления — здесь мы задаем режим загрузки и установки обновлений и расписание, по которому обновления будут устанавливаться. Если расписание не задано, то по умолчанию обновления будут устанавливаться ежедневно в 3 часа ночи.

Частота поиска автоматических обновлений — указываем частоту обращений к серверу для проверки на наличие обновлений. Теперь обращения к серверу WSUS будут происходить через заданный промежуток времени со случайным отклонением для проверки наличия разрешенных для установки обновлений.

Перенос запланированных автоматических установок обновлений — задаем время ожидания перед установкой обновлений в том случае, если плановая установка была пропущена по каким либо причинам.

Не выполнять автоматическую перезагрузку, если в системе работают пользователи — даем пользователю возможность выбора времени перезагрузки после установки обновлений. Если этот параметр не задан или отключен, то пользователю выдается уведомление и компьютер автоматически перезагружается через 5 минут.

Реестр

Теперь те же настройки произведем с помощью правки реестра.

Идем в раздел реестра HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdate. Если раздела нет — создаем его. В разделе создаем следующие ключи:

″WUServer″=http://192.168.0.1 — адрес сервера обновлений;
″WUStatusServer″=http://192.168.0.1 — адрес сервера статистики;
″TargetGroupEnabled″=dword:00000001 — размещать компьютер в целевой группе;
″TargetGroup″=″Workgroup″ — имя целевой группы для компьютера.

Далее в разделе HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdateAU создаем ключи:

″NoAutoUpdate″=dword:00000000 — автоматическое обновление включено;
″AUOptions″=dword:00000004 — загружать и устанавливать обновления по расписанию;
″ScheduledInstallDay″=dword:00000001 — устанавливать обновления в 1-й день недели (воскресенье). Для ежедневного обновления нужно задать нулевое значение;
″ScheduledInstallTime″=dword:00000003 — устанавливать обновления в 03:00 часа;
″UseWUServer″=dword:00000001 — использовать для обновлений сервер WSUS. Если задано нулевое значение, то обновление производится с Microsoft Update;
″DetectionFrequencyEnabled″=dword:00000001 — частота проверки обновлений включена;
″DetectionFrequency″=dword:00000012 — проверять наличие обновлений на сервере каждые 12 часов;
″RescheduleWaitTimeEnabled″=dword:00000001 — переносить пропущенную установку обновлений;
″RescheduleWaitTime″=dword:00000010 — запускать пропущенную установку обновлений через 10 минут после включения компьютера;
″NoAutoRebootWithLoggedOnUsers″=dword:00000001 — не перезагружать компьютер автоматически, если на нем работают пользователи.

Автоматизация настройки

Если настраивать предстоит не один компьютер, то процесс можно автоматизировать. Для этого открываем Блокнот, создаем reg-файл и добавляем в необходимые ключи реестра. В нашем случае получился вот такой файл:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdate]
″WUServer″=″http://192.168.0.1″
″WUStatusServer″=″http://192.168.0.1″
″TargetGroupEnabled″=dword:00000001
″TargetGroup″=″Workgroup″

[HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdateAU]
″NoAutoUpdate″=dword:00000000
″AUOptions″=dword:00000004
″ScheduledInstallDay″=dword:00000001
″ScheduledInstallTime″=dword:00000003
″UseWUServer″=dword:00000001
″DetectionFrequencyEnabled″=dword:00000001
″DetectionFrequency″=dword:00000012
″RescheduleWaitTimeEnabled″=dword:00000001
″RescheduleWaitTime″=dword:00000010
″NoAutoRebootWithLoggedOnUsers″=dword:00000001

Теперь для настройки автоматического обновления будет достаточно перенести этот файл на целевой компьютер и выполнить его.

Возможные проблемы

Если после настройки компьютеры не появляются в консоли WSUS, это может быть связано с тем, что рабочие станции подготовлены с использованием неправильно подготовленных образов, т.е. без использования утилиты sysprep или аналогичных программ. В этом случае машина может иметь дублирующие значения SusClientID в реестре.

Для решения проблемы необходимо произвести на клиенте следующие действия:

Источник

Настройка клиентов WSUS с помощью групповых политик

В одной из предыдущих статей мы подробно описали процедуру установки сервера WSUS на базе Windows Server 2012 R2 / 2016. После того, как вы настроили сервер, нужно настроить Windows-клиентов (сервера и рабочие станции) на использование сервера WSUS для получения обновлений, чтобы клиенты получали обновления с внутреннего сервера обновлений, а не с серверов Microsoft Update через Интернет. В этой статье мы рассмотрим процедуру настройки клиентов на использование сервера WSUS с помощью групповых политик домена Active Directory.

Групповые политики AD позволяют администратору автоматически назначить компьютеры в различные группы WSUS, избавляя его от необходимости ручного перемещения компьютеров между группами в консоли WSUS и поддержки этих групп в актуальном состоянии. Назначение клиентов к различным целевым группам WSUS основывается на метке в реестре на клиенте (метки задаются групповой политикой или прямым редактированием реестра). Такой тип соотнесения клиентов к группам WSUS называется client side targeting (Таргетинг на стороне клиента).

Предполагается, что в нашей сети будут использоваться две различные политики обновления — отдельная политика установки обновлений для серверов (Servers) и для рабочих станций (Workstations). Эти две группы нужно создать в консоли WSUS в секции All Computers.

В первую очередь необходимо указать правило группировки компьютеров в консоли WSUS (targeting). По умолчанию в консоли WSUS компьютеры распределяются администратором по группам вручную (server side targeting). Нас это не устраивает, поэтому укажем, что компьютеры распределяются в группы на основе client side targeting (по определенному ключу в реестре клиента). Для этого в консоли WSUS перейдите в раздел Options и откройте параметр Computers. Поменяйте значение на Use Group Policy or registry setting on computers (Использовать на компьютерах групповую политику или параметры реестра).

Теперь можно создать GPO для настройки клиентов WSUS. Откройте доменную консоль управления групповыми политиками (Group Policy Management) и создайте две новые групповые политики: ServerWSUSPolicy и WorkstationWSUSPolicy.

Групповая политика WSUS для серверов Windows

Начнем с описания серверной политики ServerWSUSPolicy.

В нашей организации мы предполагаем использовать данную политику для установки обновлений WSUS на сервера Windows. Предполагается, что все попадающие под эту политику компьютеры будут отнесены к группе Servers в консоли WSUS. Кроме того, мы хотим запретить автоматическую установку обновлений на серверах при их получении. Клиент WSUS должен просто скачать доступные обновления на диск, отобразить оповещение о наличии новых обновлений в системном трее и ожидать запуска установки администратором (ручной или удаленной с помощью модуля PSWindowsUpdate) для начала установки. Это значит, что продуктивные сервера не будут автоматически устанавливать обновления и перезагружаться без подтверждения администратора (обычно эти работы выполняются системным администратором в рамках ежемесячных плановых регламентных работ). Для реализации такой схемы зададим следующие политики:

Политика установки обновлений WSUS для рабочих станций

Мы предполагаем, что обновления на клиентские рабочие станции, в отличии от серверной политики, будут устанавливаться автоматически ночью сразу после получения обновлений. Компьютеры после установки обновлений должны перезагружаться автоматически (предупреждая пользователя за 5 минут).

В данной GPO (WorkstationWSUSPolicy) мы указываем:

В Windows 10 1607 и выше, несмотря на то, что вы указали им получать обновления с внутреннего WSUS, все еще могут пытаться обращаться к серверам Windows Update в интернете. Эта «фича» называется Dual Scan. Для отключения получения обновлений из интернета нужно дополнительно включать политику Do not allow update deferral policies to cause scans against Windows Update (ссылка).

Назначаем политики WSUS на OU Active Directory

Следующий шаг – назначить созданные политики на соответствующие контейнеры (OU) Active Directory. В нашем примере структура OU в домене AD максимально простая: имеются два контейнера – Servers (в нем содержаться все сервера организации, помимо контроллеров домена) и WKS (Workstations –компьютеры пользователей).

Чтобы назначить политику на OU, щелкните в консоли управления групповыми политиками по нужному OU, выберите пункт меню Link as Existing GPO и выберите соответствующую политику.

Точно таким же способом нужно назначить политику WorkstationWSUSPolicy на контейнер AD WKS, в котором находятся рабочие станции Windows.

Осталось обновить групповые политики на клиентах для привязки клиента к серверу WSUS:

Все настройки системы обновлений Windows, которые мы задали групповыми политиками должны появится в реестре клиента в ветке HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdate.

Данный reg файл можно использовать для переноса настроек WSUS на другие компьютеры, на которых не удается настроить параметры обновлений с помощью GPO (компьютеры в рабочей группе, изолированных сегментах, DMZ и т.д.)

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdate]
«WUServer»=»http://srv-wsus.winitpro.ru:8530»
«WUStatusServer»=»http://srv-wsus.winitpro.ru:8530»
«UpdateServiceUrlAlternate»=»»
«TargetGroupEnabled»=dword:00000001
«TargetGroup»=»Servers»
«ElevateNonAdmins»=dword:00000000
[HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdateAU]
«NoAutoUpdate»=dword:00000000 –
«AUOptions»=dword:00000003
«ScheduledInstallDay»=dword:00000000
«ScheduledInstallTime»=dword:00000003
«ScheduledInstallEveryWeek»=dword:00000001
«UseWUServer»=dword:00000001
«NoAutoRebootWithLoggedOnUsers»=dword:00000001

Также удобно контролировать применённые настройки WSUS на клиентах с помощью rsop.msc.

И через некоторое время (зависит от количества обновлений и пропускной способности канала до сервера WSUS) нужно проверить в трее наличие всплывающего оповещений о наличии новых обновлений. В консоли WSUS в соответствующих группах должны появиться клиенты (в табличном виде отображается имя клиента, IP, ОС, процент их «пропатченности» и дата последнего обновлений статуса). Т.к. мы политиками привязали компьютеры и серверы к различным группам WSUS, они будут получать только обновления, одобренные к установке на соответствующие группы WSUS.

Также иногда приходится принудительно перерегистрировать клиента на сервере WSUS:

wuauclt /detectnow /resetAuthorization

В особо сложных случаях можно попробовать починить службу wuauserv так. При возникновении ошибки 0x80244010 при получении обновлений на клиентах, попробуйте изменить частоту проверки обновлений на сервере WSUS с помощью политики Automatic Update detection frequency.

В следующей статье мы опишем особенности одобрения обновлений на сервере WSUS. Также рекомендуем ознакомиться со статьей о переносе одобренных обновлений между группами на 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

Совет. Данные политики находятся в разделе Computer ConfigurationAdministrative TemplatesWindows ComponentsWindows UpdateDefer Windows Updates. Благодаря этим политикам пользователь может отложить установку апгрейдов Windows 10, таким образом ОС переключается в режим Current Branch for Business. Откладывание установки обновлений не относится к обновлениям безопасности.

Чтобы исключить ситуацию с 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.

Windows 10 не может загрузить пакеты апгрейдов с WSUS (0x80244019)

WSUS на базе Windows Server 2012 и выше поддерживает возможность установки на Windows 10 не только обычных обновлений безопасности и исправлений, но и крупных пакетов обновлений (в терминологии Microsoft – апгрейдов). Но прямо из коробки этот функционал не работает, такие апгрейды (в концепции Windows 10 называются Redstone ) на клиенты просто не закачиваются. Разберемся в проблеме.

Во WSUS на Windows Server 2012 появился новый тип классов обновлений – Upgrades. Включается он в консоли WSUS в разделе Options ->Product and Classification -> вкладка Classification. Нас интересует опция Upgrades (если она не включена, не спешите ее включать!).

Если включить эту опцию, то сервер WSUS все равно не будет загружать апгрейды, выдавая при загрузке ошибку. Чтобы сервер WSUS начал скачивать пакеты апгрейдов, нужно на WSUS сервере установить отдельное обновление: KB 3095113 (https://support.microsoft.com/en-us/kb/3095113).

Примечание. Если у вас ранее уже была активирована классификация Upgrades и выполнялась синхронизация, после установки KB 3095113 придется провести очистку базы WSUS с помощью следующих PowerShell команд:

1. Отключаем классификацию Upgrades Get-WsusClassification | Where-Object -FilterScript <$_.Classification.Title -Eq “Upgrades”>| Set-WsusClassification –Disable
2. Удаляем из базы информацию об этик апгрейдах $wsus = Get-WsusServer
   $wsus.SearchUpdates(“version 1511, 10586, 1607”) | foreach
3. Осталось включить классификацию Upgrades Get-WsusClassification | Where -FilterScript <$_.Classification.Title -Eq “Upgrades”>| Set-WsusClassification
4. И повторно запустить синхронизацию. $sub = $s.GetSubscription()
   $sub.StartSynchronization()

Но это еще не все, даже после установки KB 3095113 на сервере, пакеты апгрейдов на клиентах все равно не появляются. В журналах WindowsUpdate.log на ПК с Windows 10 появляется можно найти ошибку 0x80244019:

2016/08/24 15:32:36.3654849 1064 2660 DownloadManager BITS job <84234abb-06ce-4251-941c-281b4424eb32>failed, updateId = 8CB55544-8521-238E-AAFB-422D647DC0A6.200, hr = 0x80190194. File URL = _http://wsus.mydomain.com:8530/Content/7C/6F5CAF07827FAE0E37739F3222603EAF38808B7C.esd, local path = C:WindowsSoftwareDistributionDownloaddc0dc85b32300fe505d5d9a2f479c1b010586.0.151029-1700.th2_release_CLIENTENTERPRISE_VOL_x64fre_en-us.esd

2016/08/24 15:33:36.3658125 1064 2660 DownloadManager Progress failure bytes total = 2659650046, bytes transferred = 18574952

2016/08/24 15:33:36.3845664 1064 2660 DownloadManager Error 0x80244019 occurred while downloading update; notifying dependent calls.

В логе видна попытка закачать файл ESD (новый формат распространения образа ОС), —7C/6F5CAF07827FAE0E37739F3222603EAF38808B7C.esd с сервера. Попробуйте открыть этот URL в браузере – появится ошибка 404. Дело в том, что этот тип файлов не разрешен в настройках IIS и его передача блокируется.

Чтобы разрешить серверу WSUS передавать ESD файлы, откройте консоль Internet Information Service (IIS) Manager, перейдите на сайт WSUS Administration и выберите каталог Content. В настройках IIS выберите раздел Mime Types.

Добавьте новый тип MIME (Add MIME type):

Расширение файла: .esd

Тип MIME: application/octet-stream

Совет. То же самое можно сделать командами:

cd %windir%system32inetsrv
appcmd set config /section:staticContent /+»[fileExtension=’.esd’,mimeType=’application/octet-stream’]»

Перезапустите службу IIS (iisreset) и выполните повторную синхронизацию на клиентах. Клиенты Windows 10 должны начать закачивать esd файлы и могут приступать к установке пакетов обновлений.

Windows 10 не получает обновления wsus

Профиль | Отправить PM | Цитировать

Изображения

	gpo.jpg
(168.9 Kb, 30 просмотров)

Добрый день. Хочу поделится решением проблемы с ошибкой скачивания обновлений с сервера WSUS после обновления релиза в Windows 10.
Столкнулся с проблемой: при обновлении Windows 10 до версии 1607, после до 1703 и сейчас до 1709, также после новой установки данных версий и ввод их в домен где есть сервер WSUS.
Долго мучился, не мог ничего найти на эту тему, приходилось сначала одно обновление (накопительное обновление KBХХХХХХ для Windows 10 новой версии 1ХХХ) устанавливать из центра обновления Windows и после этого опять всё работало! Но это когда было 2-3 машины, то не очень затрудняло, но когда больше, начало напрягать!
Опять погрузился в поиски, и ура! нашел.

1. Надо дописать в групповых политиках альтернативный сервер загрузок! и обновить на локальной машине gpupdate /force (можно перегрузить, для большей надежности)
2. Была ошибка в адресе http://wsus:8530/ надо без слэша на конце http://wsus:8530 (до этого все работало и со слэшем лет 10)
3. Надо удалить два файла на локальной машине по пути C:WINDOWSSoftwareDistributionDataStore DataStore.edb и DataStore.jfm (если не удается, остановите службу обновления)
4. Удалить компьютер из WSUS
5. Должна работать служба брандмауэра

Запускаем заново повтор установки обновления и через несколько минут наблюдаем загрузку обновлений!
Надеюсь кому то поможет.

Служба самостоятельного обновления WSUS не отправляет автоматические обновления

В этой статье приводится решение проблемы, из-за которой клиентские компьютеры не получают обновления при использовании службы самостоятельного обновления Microsoft cлужбы Windows Server Update Services (WSUS) для отправки автоматических обновлений.

Исходная версия продукта: Windows Server 2012 R2
Исходный номер КБ: 920659

Симптомы

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

В этом случае консоль администрирования WSUS занося в журнал следующее сообщение об ошибке:

Проверьте конфигурацию сервера. Не удалось связаться с одним или более компонентами службы обновления. Проверьте состояние сервера и убедитесь, что служба Обновления Windows Server запущена.
Не работающие службы: selfUpdate

Журнал событий также может включать следующее событие:

Причина

Эта проблема может возникнуть, если верно одно или несколько из следующих условий:

• Отсутствуют или неправильно настроены разрешения для каталога, или IUSR_ ComputerName была удалена из группы C:Program FilesUpdate ServiceSelfUpdate «Пользователи».
• Виртуальный каталог SelfUpdate отсутствует на сервере WSUS.
• Виртуальный каталог SelfUpdate не настроен для сайта по умолчанию через порт 80.
• Виртуальный каталог SelfUpdate не имеет разрешений анонимного доступа.
• Веб-сайт по умолчанию настроен на использование указанных IP-адресов и отсутствует запись для 127.0.0.1.
• Веб-сайт по умолчанию не имеет разрешений анонимного доступа.
• На сервере WSUS также установлена Windows SharePoint Services Microsoft. Ресурсы WSUS не были исключены из управления SharePoint.
• Установка Selfupdate.msi неисправна. Таким образом, файлы отсутствуют в подпапок

Решение

Чтобы устранить эту проблему, необходимо иметь следующие минимальные разрешения для каталога C:Program FilesUpdate ServiceSelfUpdate.

Group	Permissions
Администраторы	Полный доступ
Системные	Полный доступ
Домен, пользователи или локальные/пользователи	Чтение&execute, Read, List Folders
IUSR_ ComputerName	Чтение&execute, Read, List Folders

IUSR_ ComputerName представляет имя хоста сервера, на котором запущены IIS, на котором установлены WSUS. Если эта учетная запись входит в группу пользователей, вам не нужно явно определять эти разрешения.

Чтобы устранить проблему, из-за которой отсутствует виртуальный каталог selfUpdate или в веб-сайте, привязанном к порту 80, отсутствует виртуальный каталог selfUpdate, запустите файл Selfupdate.msi, расположенный в папке Program filesUpdate servicesSetup.

Чтобы устранить проблемы, из-за которых у виртуального каталога SelfUpdate нет разрешений на анонимный доступ, откройте диспетчер IIS, разойдите веб-сайт по умолчанию, щелкните правой кнопкой мыши виртуальный каталог SelfUpdate и выберите «Свойства» . На вкладке «Безопасность каталога» щелкните «Изменить» в области «Проверка подлинности» и «Управление доступом». Убедитесь, что анонимный доступ включен.

Этот шаг также следует выполнить для веб-сайта по умолчанию. Дерево selfUpdate не работает, если имеется веб-сайт, привязанный к определенному IP-адресу в конфигурации IIS. Обходным решением является либо настройка конфигурации IIS для ответа на «Все ненаправленные» адреса, либо добавление 127.0.0.1 в список IP-адресов, используемых для selfUpdate.

Используйте консоль управления СЛУЖБЫ IIS, чтобы убедиться, что на сервере настроена одна из следующих двух конфигураций.

Конфигурация 1: службы WSUS установлены на веб-сайте по умолчанию

Настройте веб-сайт по умолчанию с помощью следующих параметров:

• SelfUpdate
• Содержимое
• ClientWebService
• SimpleAuthWebService
• WSUSAdmin
• ReportingWebService
• DssAuthWebService
• ServerSyncWebService

Конфигурация 2: службы WSUS установлены на настраиваемом веб-сайте

Настройте веб-сайт по умолчанию на порту 80 с помощью следующих параметров:

Настройте администрирование WSUS на порту 8530 со следующими настройками:

• SelfUpdate
• Содержимое
• ClientWebService
• SimpleAuthWebService
• WSUSAdmin
• ReportingWebService
• DssAuthWebService
• ServerSyncWebService

Независимо от выбранной конфигурации необходимо также проверить следующие параметры:

• Необходимо настроить виртуальный каталог selfUpdate на веб-сайте по умолчанию или любом другом веб-сайте для прослушивания порта 80.
• Виртуальный каталог SelfUpdate указывает на C:Program FilesUpdate ServiceSelfUpdate.
• Виртуальный каталог WSUSAdmin — это единственный виртуальный каталог в СЛУЖБАХ IIS, для системы безопасности должен быть установлена встроенная проверка подлинности Windows. Установите для всех остальных виртуальных каталогов безопасность «Анонимный доступ включен».

Status

Корпорация Майкрософт подтвердила, что это проблема.

Дополнительные сведения

При использовании служб IIS можно переместить каталог SelfUpdate на другой веб-сайт. Для этого выполните следующие действия:

1. Нажмите кнопку«Начните», щелкните «Выполнить»,введите«Администрирование управления», а затем дважды щелкните диспетчер служб IIS.
2. Разйдите папку «Веб-сайты» и выберите узел администрирования WSUS.
3. Щелкните правой кнопкой мыши узел SelfUpdate, найдите пункт «Все задачи» и выберите «Сохранить конфигурацию в файл».
4. Введите имя файла и сохраните его в другой папке. Этот файл будет применяться в шагах с 9 по 12.
5. Щелкните правой кнопкой мыши узел ClientWebService, выберите «Все задачи» и выберите «Сохранить конфигурацию в файл».
6. Введите имя файла и сохраните его в той же папке, которая использовалась на шаге 4. Этот файл будет применяться в шагах 13-15.
7. Выберите веб-сайт по умолчанию или другой веб-сайт, работающий на порту 80.
8. Щелкните веб-сайт правой кнопкой мыши, выберите пункт «Новый» и выберите виртуальный каталог (из файла).
9. Выберите каталог, в котором сохранены самоустановка и ClientWebService.xml в шагах 4 и 6.
10. Выберите файл SelfUpdate.xml и нажмите кнопку «Открыть».
11. Нажмите кнопку «Чтение файла», выберите файл selfUpdate, который теперь указан в списке «Выберите конфигурацию для импорта» и нажмите кнопку «ОК».
12. В диалоговом окне «Диспетчер IIS» введите имя нового виртуального каталога в поле «Псевдоним» и нажмите кнопку «ОК».
13. Выберите XML-файл ClientWebService и нажмите кнопку «Открыть».
14. Нажмите кнопку «Чтение файла», выберите файл selfUpdate, который теперь указан в списке «Выберите конфигурацию для импорта» и нажмите кнопку «ОК».
15. В диалоговом окне «Диспетчер IIS» введите имя нового виртуального каталога в поле «Псевдоним» и нажмите кнопку «ОК».
16. Если это новый веб-сайт, запустите его в диспетчере IIS. Если это существующий веб-сайт, перезапустите его из диспетчера IIS.

Ссылки

Дополнительные сведения об автоматических обновлениях в Windows см. в описании функции автоматического обновления в Windows.

Устранение неполадок с агентами клиентов WSUS

В этой статье вы можете диагностировать и устранять проблемы с агентами cлужбы Windows Server Update Services (WSUS).

Оригинальная версия продукта: cлужбы Windows Server Update Services
Исходный номер КБ: 10132

При проблемах с агентами клиентов WSUS они могут проявляться многими способами. Ниже перечислены некоторые распространенные проблемы:

• Это может быть проблемой с настройками клиента для групповой политики.
• Это может быть проблема с BITS.
• Это может быть проблема со службой агентов WSUS.
• Это может быть связано с сетевой проблемой, которая не позволяет клиенту достичь сервера.
• Это может быть проблема с магазином агентов автоматического обновления.
• Это может быть проблема, из-за которой у клиентов имеются дублирующиеся ID клиента WSUS, вызванные клонированием дисков.

Убедитесь, что клиент настроен правильно

При устранении неполадок с клиентом WSUS сначала убедитесь, что клиент правильно настроен. Убедитесь, что клиент получает соответствующую групповую политику Active Directory, а также сведения о сервере WSUS. Это можно сделать, подав следующую команду:

Откройте текстовый файл в блокноте и найдите имя политики WSUS. Например, если политика WSUS называется WSUS, ее можно найти в файле GPRESULT.TXT в разделе Параметры компьютера в разделе Объекты прикладной групповой политики. Ниже приведен пример:

Если параметров WSUS нет, возможные причины:

• В системе нет групповой политики из домена.
• Групповой политика не ориентирована на клиентскую систему.

Чтобы устранить эту проблему, убедитесь в успешном обновлении групповой политики для каждого клиента и правильной настройке параметра WSUS.

Чтобы обновить групповую политику клиента, запустите GPUpdate /force из командной подсказки.

Дополнительные сведения о настройке групповой политики для клиентов WSUS см. в дополнительных сведениях о настройке автоматических обновлений с помощью групповой политики.

Проверка проблем, связанных с BITS

Background Intelligent Transfer Service (BITS) — это служба, используемая WSUS для скачивания обновлений из Microsoft Update на основной сервер WSUS и с серверов WSUS для своих клиентов. Некоторые проблемы с загрузкой могут быть вызваны проблемами с битами на сервере или клиентских компьютерах. При устранении неполадок при загрузке необходимо убедиться, что bits работает должным образом на всех затронутых компьютерах.

Служба BITS должна работать под учетной записью LocalSystem по умолчанию. Чтобы настроить службу для работы под правильной учетной записью, выполните следующие действия:

Откройте командную подсказку и запустите следующую команду:

Между obj= и LocalSystem должно возникать пространство. В случае успешной работы необходимо получить следующий вывод:

Остановка и перезапуск BITS.

Чтобы просмотреть состояние службы BITS, откройте командную подсказку и запустите следующую команду:

Если биты запущены, вы должны увидеть следующий вывод:

Если BITS не запущен, вы увидите следующий вывод:

Обычно можно разрешить проблемы с BITS, остановив службу и перезапустив ее. Чтобы остановить и перезапустить службу BITS, запустите следующие команды из командной подсказки:

Чтобы остановить и перезапустить BITS, необходимо войти в систему в качестве локального администратора.

BITS не удается запустить

Если служба BITS не запустится, в журнале событий можно найти любую ошибку, связанную с БИТС. Для диагностики причин этих ошибок можно использовать следующую таблицу.

Имя ошибки	Код ошибки	Описание
ERROR_SERVICE_DOES_NOT_EXIST	0x80070424	Ниже см. раздел о восстановлении конфигурации BITS.
ERROR_SERVICE_NOT_IN_EXE	0x8007043B	BITS не указан в качестве одной из служб в группе svchost netsvcs
ERROR_SERVICE_DISABLED	0x80070422	Биты отключены. Включить службу BITS.
ERROR_SERVICE_DEPENDENCY_DELETED ERROR_SERVICE_DEPENDENCY_FAIL	0x80070433, 0x8007042c	Служба, появляемая в списке зависимостей службы BITS, не может быть запущена. Убедитесь, что список зависимостей для службы BITS является правильным: Windows Vista: RpcSs, EventSystem (также http.sys и LanManWorkstation при включенном одноранговом кэшинге) Windows Server 2003: Rpcss, EventSystem Windows XP: Rpcss Windows 2000: Rpcss, SENS, Wmi
ERROR_PATH_NOT_FOUND	0x80070003	Pre-Windows Vista: %ALLUSERSPROFILE%MicrosoftNetwork не существует
ERROR_FILE_NOT_FOUND	0x80070002	Ключ Параметры отсутствует. Убедитесь, что существуют следующие ключи и значения: HKLMSYSTEMCurrentControlSetServicesBITSParametersServiceDll = %SystemRoot%System32qmgr.dll
REGDB_E_CLASSNOTREG, EVENT_E_INTERNALERROR	0x80040154, 0x80040206	BITS для Windows 2000 зависит от служб SENS и EventSystem. Если каталог COM+ поврежден, bits может привести к сбою с этим кодом ошибки.

Задания BITS не удается

Если клиент правильно настроен для получения обновлений, биты настроены правильно, а биты, как представляется, начинаются и работают должным образом, может возникнуть проблема, из-за которой сами задания BITS не работают. Чтобы проверить это, посмотрите в журнале событий все ошибки, связанные с BITS. Для диагностики причин этих ошибок можно использовать следующую таблицу.

Имя ошибки	Код ошибки	Описание
E_INVALIDARG	0x80070057	Неправильное имя прокси-сервера было указано в параметрах прокси-сервера Internet Explorer пользователя. Эта ошибка также рассматривается при поставке учетных данных для схем проверки подлинности, которые не являются NTLM/Negotiate, но имя пользователя или пароль являются null. Измените параметры прокси-сервера Internet Explorer пользователя на допустимый прокси-сервер. Или измените учетные данные, чтобы они не были NULL-именем пользователя или паролем для схем, помимо NTLM/Negotiate.
ERROR_WINHTTP_NAME_NOT_RESOLVED	0x80072ee7	Сервер/прокси-сервер не удалось разрешить с помощью BITS. Internet Explorer на той же машине в контексте владельца задания будет видеть ту же проблему. Попробуйте загрузить один и тот же файл через веб-браузер с помощью контекста владельца задания.
ERROR_HTTP_INVALID_SERVER_RESPONSE	0x80072f78	Это преходящая ошибка, и задание будет продолжать скачивать.
BG_E_INSUFFICIENT_RANGE_SUPPORT	0x80200013	BITS использует заглавные элементы диапазона в http-запросах для запроса частей файла. Если сервер или прокси-сервер не понимают диапазон запросов и возвращает полный файл вместо запрашиваемого диапазона, BITS ставит задание в состояние ERROR с этой ошибкой. Захват сетевого трафика во время ошибки и проверьте, получают ли запросы HTTP GET с помощью заголовка Range допустимые ответы. Проверьте прокси-серверы, чтобы убедиться, что они правильно настроены для поддержки запросов range.
BG_E_MISSING_FILE_SIZE	0x80200011	Когда BITS отправляет HEAD-запрос, а сервер/прокси-сервер не возвращает в ответ заготвку Content-Length, BITS ставит задание в состояние ERROR с этой ошибкой. Проверьте прокси-сервер и сервер WSUS, чтобы убедиться, что они настроены правильно. Известно, что это поведение проявляется в некоторых версиях прокси-сервера Apache 2.0.
BG_E_HTTP_ERROR_403	0x80190193	Когда сервер возвращает ответ HTTP 403 в любом из запросов, BITS ставит задание в состояние ERROR с этим кодом ошибки. HTTP 403 соответствует запрету: доступ запрещен. Проверьте разрешения доступа для учетной записи, которая работает с заданием.
ERROR_NOT_LOGGED_ON	0x800704dd	Служба SENS не получает уведомления о логотипе пользователя. Bits (версия 2.0 и более поздние версии) зависит от уведомлений с логотипом от диспетчера управления службой, что, в свою очередь, зависит от службы SENS. Убедитесь, что служба SENS запущена и запущена правильно.

Ремонт поврежденной конфигурации BITS

Чтобы восстановить поврежденную конфигурацию службы BITS, можно ввести конфигурацию службы BITS вручную.

Это действие следует предпринять только в тех случаях, когда все другие попытки устранения неполадок потерпели неудачу. Чтобы изменить конфигурацию BITS, необходимо быть администратором.

Чтобы восстановить поврежденную конфигурацию BITS, выполните следующие действия:

Откройте командную подсказку.

Введите следующие команды, нажмите ВВОД после ввода каждой команды:

Остановка и перезапуск BITS.

Проблемы со службой агентов WSUS

Убедитесь, что служба обновления Windows может успешно запуститься.

Чтобы просмотреть текущее состояние службы обновления Windows, откройте командную подсказку и запустите следующую команду:

Если WUAUSERV запущен, вы должны увидеть следующий вывод:

Если WUAUSERV не запущен, вы увидите следующий вывод:

Убедитесь, что вы можете успешно запустить службу WUAUSERV. Чтобы остановить и перезапустить WUAUSERV, необходимо войти в систему в качестве локального администратора.

Чтобы запустить службу WUAUSERV, запустите следующие команды из командной подсказки:

Если агент клиента не запустится должным образом, проверьте версию агента обновления Windows. Если агент не обновлен, обнови агент обновления Windows до последней версии.

После запуска исправления или обновления агента запустите wuauclt /detectnow . Проверьте windowsupdate.log, чтобы убедиться, что нет проблем.

Убедитесь, что сервер WSUS можно достичь от клиента

Убедитесь, что вы можете получить доступ к URL-адресу http:// /iuident.cab и скачать файл без ошибок.

Если сервер WSUS недостижим от клиента, наиболее вероятными причинами являются следующие:

• У клиента есть проблема с разрешением имен.
• Существует проблема, связанная с сетью, например проблема конфигурации прокси.

Используйте стандартные процедуры устранения неполадок, чтобы убедиться, что разрешение имен работает в сети. Если разрешение имен работает, следующим шагом является проверка проблем с прокси-серверами. Проверьте windowsupdate.log (C:windows), чтобы узнать, есть ли ошибки, связанные с ) прокси. Вы можете запустить proxycfg команду, чтобы проверить параметры прокси WinHTTP.

При ошибках прокси перейдите в lan-параметры Internet Explorer > Tools Connections, настройте правильный прокси и убедитесь, что вы можете получить доступ к > > указанному URL-адресу WSUS.

После этого можно скопировать эти параметры прокси-сервера пользователя в прокси-параметры WinHTTP с помощью proxycfg -u команды. После заданных параметров прокси запустите из командного запроса и проверьте wuauclt /detectnow windowsupdate.log на факт ошибок.

Восстановление магазина агентов автоматического обновления

При проблемах с загрузкой обновлений и ошибках, связанных с магазином рассылки программного обеспечения, выполните следующие действия на клиенте:

• Остановите службу автоматических обновлений, sc stop wuauserv выключив командный запрос.
• Переименовать папку рассылки программного обеспечения (например, C:WindowsSoftwareDistribution).
• Перезапустите службу автоматического обновления с sc start wuauserv помощью командной подсказки.
• Из командного запроса запустите wuauclt /resetauthorization /detectnow .
• Из командного запроса запустите wuauclt /reportnow .

Проверка для клиентов с тем же ИД SUSclient

Может возникнуть проблема, из-за которой на консоли появляется только один клиент WSUS. Или вы можете заметить, что из группы клиентов на консоли одновременно появляется только один, но точный, который появится, со временем может измениться. Эта проблема может произойти, когда системы изображения и клиенты в конечном итоге с той же SUSclientID .

Для тех клиентов, которые не работают должным образом из-за того SUSclientID же, выполните следующие действия:

Остановите службу автоматических обновлений, sc stop wuauserv выключив командный запрос.

Удаление SUSclientID ключа реестра из следующего расположения:

Перезапустите службу автоматического обновления с sc start wuauserv помощью командной подсказки.

Из командного запроса запустите wuauclt /resetauthorization /detectnow .

Из командного запроса запустите wuauclt /reportnow .