Download Windows Speedup Tool to fix errors and make PC run faster
You can prevent Windows 11/10 from connecting to any Windows Update Internet locations using Local Group Policy Editor and Registry Editor. This way, you can stop Windows from connecting to those locations and block it from fetching, downloading, and installing updates.
When Windows Update is configured to receive updates from an Intranet update service, it begins to retrieve information from the public Windows Update service periodically.
This event occurs by design to enable future connections to Windows Update and other services like Microsoft Update or the Windows Store. You can prevent this behavior i.e., stop Windows from connecting to any Windows Update Internet locations.
To prevent Windows from connecting to any Windows Update Internet locations using Registry Editor, follow these steps:
- Open Registry Editor on your PC.
- Go to WindowsUpdate in HKLM.
- Double-click on DoNotConnectToWindowsUpdateInternetLocations.
- Set the Value data to 1.
- Click the OK button.
- Close all windows and restart your computer.
To learn more about these steps, continue reading.
Press Win+R in combination to open the Run dialog box. Type regedit in the empty field of the box and press Enter.
When the Registry Editor opens, navigate to the following path address –
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate.
Here, switch to the right pane, right-click, and select DWORD. Name it as:
DoNotConnectToWindowsUpdateInternetLocations
Double-click the entry to edit the string value. Change it to 1.
However, if you cannot find the DoNotConnectToWindowsUpdateInternetLocations REG_DWORD value, you need to create it manually. For that, right-click on the WindowsUpdate key > New > DWORD (32-bit) Value and set the name as mentioned above.
Simply close the Registry Editor and exit.
Restart your PC to allow the changes to take effect.
The registry changes when configured will enable Do not connect to any Windows Update Internet locations GPO setting and stop Windows from connecting to any Windows Update Internet locations.
This setting is applicable only when this PC is set up to connect to an intranet update service using the ‘Specify intranet Microsoft update service location’ policy.
Stop Windows from connecting to any Windows Update Internet locations using Group Policy
To stop Windows from connecting to any Windows Update Internet locations using Group Policy, follow these steps:
- Open the Local Group Policy Editor.
- Navigate to Computer Configuration > Administrative Templates > Windows Components> Windows Update > Manage updates offered from Windows Server Update Service.
- Double-click on the Do not connect to any Windows Update Internet locations setting.
- Choose the Enabled option.
- Click the OK button.
To learn more about these steps, keep reading.
Computer Configuration > Administrative Templates > Windows Components> Windows Update.
Under Windows Update Setting, open Do not connect to any Windows Update Internet locations.
Check the Enabled option to enable the policy.
Instantly, the connection to public services such as the Microsoft Store, and Windows Update will stop working.
Hope this helps.
Read: How to add Windows Updates to Context Menu in Windows
How do I stop Windows Update from using the Internet?
You need to disable the Windows Update service to stop Windows Update from using the internet. Open the Services panel and double-click on the Windows Update service. Then, click the Stop button. Click the Apply and OK buttons.
How do I turn off Windows Update in Windows 11 permanently?
To turn off Windows Update in Windows 11 permanently, you must disable the Windows Update service. For that, do the following:
- Press Win+R.
- Type services.msc and hit Enter.
- Double-click on Windows Update.
- Click the Stop button.
- Click the OK button.
Read: Windows was unable to get a list of devices from Windows Update.
Anand Khanse is the Admin of TheWindowsClub.com, a 10-year Microsoft MVP (2006-16) & a Windows Insider MVP (2016-2022). Please read the entire post & the comments first, create a System Restore Point before making any changes to your system & be careful about any 3rd-party offers while installing freeware.
Реализация DI в PHP
Jason-Webb 13.05.2025
Когда я начинал писать свой первый крупный PHP-проект, моя архитектура напоминала запутаный клубок спагетти. Классы создавали другие классы внутри себя, зависимости жостко прописывались в коде, а о. . .
Обработка изображений в реальном времени на C# с OpenCV
stackOverflow 13.05.2025
Объединение библиотеки компьютерного зрения OpenCV с современным языком программирования C# создаёт симбиоз, который открывает доступ к впечатляющему набору возможностей. Ключевое преимущество этого. . .
POCO, ACE, Loki и другие продвинутые C++ библиотеки
NullReferenced 13.05.2025
В C++ разработки существует такое обилие библиотек, что порой кажется, будто ты заблудился в дремучем лесу. И среди этого многообразия POCO (Portable Components) – как маяк для тех, кто ищет. . .
Паттерны проектирования GoF на C#
UnmanagedCoder 13.05.2025
Вы наверняка сталкивались с ситуациями, когда код разрастается до неприличных размеров, а его поддержка становится настоящим испытанием. Именно в такие моменты на помощь приходят паттерны Gang of. . .
Создаем CLI приложение на Python с Prompt Toolkit
py-thonny 13.05.2025
Современные командные интерфейсы давно перестали быть черно-белыми текстовыми программами, которые многие помнят по старым операционным системам. CLI сегодня – это мощные, интуитивные и даже. . .
Конвейеры ETL с Apache Airflow и Python
AI_Generated 13.05.2025
ETL-конвейеры – это набор процессов, отвечающих за извлечение данных из различных источников (Extract), их преобразование в нужный формат (Transform) и загрузку в целевое хранилище (Load). . . .
Выполнение асинхронных задач в Python с asyncio
py-thonny 12.05.2025
Современный мир программирования похож на оживлённый мегаполис – тысячи процессов одновременно требуют внимания, ресурсов и времени. В этих джунглях операций возникают ситуации, когда программа. . .
Работа с gRPC сервисами на C#
UnmanagedCoder 12.05.2025
gRPC (Google Remote Procedure Call) — открытый высокопроизводительный RPC-фреймворк, изначально разработанный компанией Google. Он отличается от традиционых REST-сервисов как минимум тем, что. . .
CQRS (Command Query Responsibility Segregation) на Java
Javaican 12.05.2025
CQRS — Command Query Responsibility Segregation, или разделение ответственности команд и запросов. Суть этого архитектурного паттерна проста: операции чтения данных (запросы) отделяются от операций. . .
Шаблоны и приёмы реализации DDD на C#
stackOverflow 12.05.2025
Когда я впервые погрузился в мир Domain-Driven Design, мне показалось, что это очередная модная методология, которая скоро канет в лету. Однако годы практики убедили меня в обратном. DDD — не просто. . .
Лично для меня было открытием, что в некоторых случаях компьютеры с Wiindows 10 могут не получать обновления со внутреннего WSUS сервера, вместо этого обращаясь в Интернет к серверам обновления Microsoft, хотя WSUS сервер для клиентов жестко установлен стандартной групповой политикой. Данная проблема связан с термином Dual Scan (не встречал на русском расшифровку термина, пусть это будет двойное сканирование).
Понятие Dual Scan представляет собой такую комбинацию настроек в Windows 10 1607 и выше, при которой клиенты начинают игнорировать настройки локального WSUS сервера, параллельно обращаясь для сканирования на наличие новых обновлений на внешние сервера Windows Update. Первые обращения с подобными проблемами были еще в мае 2017 года.
Сканирование обновлений выполняется одновременно и на WSUS сервере и на серверах WU, однако клиент принимает апдейты только от серверов WU. Таким образом, все обновления/патчи с локального WSUS, относящиеся к категории Windows будут игнорироваться такими клиентами. Т.е. обновления Windows в таком режиме получаются из интернета, а обновления драйверов и других продуктов со WSUS.
В моем случае на проблемном клиенте, в разделе Computer Configuration\Administrative Templates\Windows Components\Windows 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 Configuration\Administrative Templates\Windows Components\Windows Update\Defer 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 Configuration\Administrative Templates\Windows Components\Windows Update.
Данная политика присутствует в Windows 10 1607, однако в Windows 10 версии 1703 ее по умолчанию нет. Чтобы данная настройка GPO появилась, нужно установить обновление KB4034658 от 8 августа 2017.
В Windows Server 2016 можно столкнуться с ситуацией, когда встроенный клиент Windows Update очень долго выполняет проверку обновлений. Характерно то, что проблема может проявляться плавающим образом и воспроизводиться не всегда. Замечено, что чаще всего проблема проявляется в случае, если система была недавно включена или перезагружена. В этой заметке мы поговорим о том, какие могут быть причины у такого поведения и как это можно попробовать исправить.
При попытке вызвать проверку обновлений из интерфейса настроек системы в Settings > Update & security > Windows Update мы можем столкнуться с длительным циклом ожидания в статусе «Checking for updates…»
Результатом такого ожидания может стать возникновение ошибки типа:
We couldn't connect to the update service. We'll try again later, or you can check now. If it still doesn't work, make sure you're connected to the Internet.
Это привносит проблемы и в других операциях обслуживания системы.
Отражение проблемы с Windows Update в Failover Cluster Manager
В качестве примера отрицательного влияния проблемной работы Windows Update можно привести мастер проверки конфигурации кластера, вызываемый из оснастки Failover Cluster Manager. В ходе выполнения валидации кластера, на этапе сбора информации об установленных на кластерных узлах обновлениях («List Software Updates«) мы можем получить состояние длительного ожидания.
В ходе изучения ситуации по следам «коллективного разума» я обнаружил, что самые разнообразные проблемы c Windows Update в Windows Server 2016 известны давно и с ними столкнулись многие:
- TechNet Forums : Windows Server 2016 Updates slow!
- Superuser : Windows Update stuck on Checking for updates
- Born’s Tech and Windows World : Windows Server 2016: Slow updates
Методом «а если попробовать…» было выявлено, что в качестве обходного решения в вышеописанной ситуации с Failover Cluster Manager, может быть простой перезапуск службы «Windows Update«.
Возможно, потребуется сделать лишь остановку этой службы, а запустится служба через несколько секунд автоматически. Если служба не остановилась с первого раза (остановка привела к ошибке), то пробуем выполнить остановку повторно. Выполнить остановку службы можно как через оснастку управления службами services.msc, так и через PowerShell.
Stop-Service "Windows Update"
Сразу после того, как служба будет остановлена (а затем сама автоматически запустится) мы увидим сдвиг в работе механизма проверки обновлений.
В случае с кластером, выполнить остановку/перезапуск службы «Windows Update» нам может потребоваться на всех узлах кластера, начиная с того, на котором запущен мастер проверки.
В попытках понять, что же не так с проверкой обновлений в Windows Server 2016 и проведения ряда экспериментов с видимыми настройками клиента Windows Update в графической среде, стало очевидно то, что наличие включённой опции «Defer feature updates» в Settings > Update & security > Windows Update > Advanced options явным образом влияет на воспроизведение проблемы.
То есть, как только мы отключаем данную опцию, включенную в Windows Server 2016 по умолчанию, то механизм проверки обновлений начинает работать так, как мы этого от него ожидаем при наличии сервера WSUS.
Дальнейшее изучение вопроса показало, что причиной странного поведения клиента Windows Update может являться механизм «Dual Scan» (подробней в статьях «Improving Dual Scan on 1607» и «Demystifying Dual Scan»), который заставляет при проверке обновлений в качестве источника использовать не только форсировано настроенный в доменных групповых политиках сервер WSUS в локальной сети, но и Интернет-службы Windows Update.
Соответственно, при условии, что компьютеры имеют ограниченный доступ в Интернет или не имеют его вовсе, может возникнуть эффект длительного ожидания с возникновением ошибок разного содержания.
Чтобы решить описанную проблему, нам потребуется провести настройку групповой политики Active Directory, с помощью которой настраиваются наши серверы на базе Windows Server 2016. Однако, как выяснилось, в этом вопросе всё не так очевидно, понятно и однозначно, как хотелось бы.
Варианты решения с готовыми политиками GPO (неработающие в нашем случае)
Примечание: Если важен только готовый рецепт и не интересны эксперименты по следам ранее предложенных в Интернете приёмов(которые в нашем случае не помогли), то можете смело пропустить этот раздел заметки и читать заключительный раздел.
В ранних выпусках Windows 10 (с версии 1607) и Windows Server 2016 за отключение попыток использования онлайн репозитория Windows Update отвечала политика:
«Do not allow update deferral policies to cause scans against Windows Update«
в разделе:
Computer Configuration > Administrative Templates > Windows Components > Windows Update.
В результате применения этой политики в системном реестре Windows появляется параметр DisableDualScan, установленный в 1:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
"DisableDualScan"=dword:00000001
И, судя по старым статьям, на более ранних версиях Windows 10 описанная политика могла быть полезна для решения проблемы.
Однако, в более поздних версиях Windows 10 (начиная с версии 2004), Windows 11, а так же, возможно, в более новых версиях Windows Server, данная политика была перенесена в подраздел Legacy Policies и была заменена новой политикой:
«Specify source service for specific classes of Windows Updates«
в разделе:
Computer Configuration > Administrative Templates > Windows Components > Windows Update > Manage updates offered from Windows Server Update Service.
Предполагается включение этой политики и выбор WSUS в качестве источника для всех предлагаемых типов обновлений.
В результате применения этой политики в системном реестре Windows появляется 4 параметра с соответствующими именами, установленных в 1:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
"SetPolicyDrivenUpdateSourceForFeatureUpdates"=dword:00000001
"SetPolicyDrivenUpdateSourceForQualityUpdates"=dword:00000001
"SetPolicyDrivenUpdateSourceForDriverUpdates"=dword:00000001
"SetPolicyDrivenUpdateSourceForOtherUpdates"=dword:00000001
Логично предполагать, что включать и настраивать данную политику резонно лишь для серверных систем, которые в локальных сетях, как правило, обновляются с сервера WSUS и имеют ограниченный доступ в Интернет. Для клиентских же систем, часть из которых может оказаться мобильными и периодически перемещающимися из локальной сети во внешние сети с доступом в Интернет, в некоторых ситуациях может оказаться логичней использовать настроенный по умолчанию механизм выбора источника (то есть, чтобы в качестве дополнительного источника мог выступать онлайн репозиторий Windows Update).
Эксперименты с двумя выше описанными политиками показали, что на данный момент времени сами по себе (ни по отдельности ни вместе) эти политики не решают проблему в нашем конкретном случае.
В ходе дальнейшего изучения опыта борьбы коллег со странностями работы Windows Update в Windows Server 2016 обнаружил статью «Windows admin blog : Некорректное отображение информации на WSUS | Проблемы обновления со WSUS (Dual Scan)», где в качестве одного из решений предложено включение «олдскульной» политики:
«Do not connect to any Windows Update Internet locations«
в разделе:
Computer Configuration > Administrative Templates > Windows Components > Windows Update > Manage updates offered from Windows Server Update Service.
В результате применения этой политики в системном реестре Windows появляется параметр DoNotConnectToWindowsUpdateInternetLocations, установленный в 1:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
"DoNotConnectToWindowsUpdateInternetLocations"=dword:00000001
Однако, практика показала, что применение данной политики может привести к появлению новой ошибки в ходе проверки обновлений:
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: (0x8024500c)
Причём избавиться от этой ошибки не поможет ни перезапуск службы, ни перезагрузка системы, а по свидетельствам очевидцев, эта ошибка воспроизводится так же и на Windows 10.
Понимая то, что данная политика не решает проблемы, можно было бы не упоминать о ней в нашей заметке. Однако помимо того, что она не только не закрывает исходную проблему, но и может создать новую трудно интерпретируемую проблему, мы и упоминаем здесь о ней, как о неподходящем варианте решения.
Перебрав ряд других групповых политик, как по одиночке, так и в в разных комбинациях, мне так и не удалось найти решения на базе каких-либо готовых политик.
Отключение опции «Defer feature updates» с помощью GPP
В конечном итоге пришлось прибегнуть к помощи Group Policy Preferences (GPP) для управления опцией «Defer feature updates«, отображаемой в графической оболочке Windows Server 2016.
Отключение данной опции приводит к следующему изменению в системном реестре:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsUpdate\UX\Settings]
"DeferUpgrade"=dword:00000000
Соответственно, для настройки серверов с Windows Server 2016 на явное отключение данной опции мы можем создать в доменной групповой политике, применяемой к серверам, объект GPP, настраивающий параметр реестра DeferUpgrade.
С помощью Item-level targeting можем указать то, что данный параметр реестра будет обновляться только на системах семейства Windows Server 2016.
Для оперативной проверки результата выполняем на конечном сервере обновление групповых политик и инициируем процедуру проверки обновлений:
gpupdate /force
UsoClient.exe startscan
Убедимся в том, что после применения GPO в реестре на серверных системах с Windows Server 2016 применились изменения и в графической консоли настроек системы опция «Defer feature updates» отображается в выключенном состоянии.
Все последующие проверки обновлений Windows теперь должны начать работать напрямую с WSUS без длительных попыток обращения к Интернет-службам Windows Update.