Оновлення Windows не працює у Windows 2012 R2 Standard

Нещодавно я успадкував управління сервером Windows 2012 на віддаленому сайті.

Я перевірив Windows Update, і він не оновлювався з березня. Коли я кажу Windows, щоб перевірити наявність оновлень, він діє так, як перевіряє, але, здається, це говорить годинами. Якщо я спробую перезапустити службу оновлення Windows, вона, здається, ніколи не зможе її вимкнути. Моїм єдиним засобом захисту є перезавантаження, щоб повернутися до того моменту, коли я можу сказати Windows Update перевірити наявність нових оновлень.

Остання успішна перевірка оновлень - 20 березня.

Востаннє було встановлено оновлення 17 березня (не вдалося).

Історія оновлень показує, що одне оновлення не вдалося 17 березня, оновлення драйвера принтера, але історія показує 13 невдалих оновлень для 17 лютого.

Не впевнений, що ще спробувати.

Дві мої три машини 2012R2 проявили цю поведінку минулого квітня. Вони будуть зависати під час перевірки оновлень ... назавжди.

Я ніколи не дізнався, що саме спричинило проблему, але вирішив це, зробивши наступне:

1. Зупиніть службу оновлення Windows.

   net stop wuauserv
   

2. Видаліть каталог кешу Windows Update C:\Windows\SoftwareDistribution.

   Remove-Item -Recurse -Force C:\Windows\SoftwareDistribution
   

3. Перезавантажте комп'ютер. (На одній машині потрібно було декілька перезавантажень, щоб фактично все було видалено з цього каталогу, тому продовжуйте намагатися, якщо потрібно).

4. Знову запустіть оновлення Windows вручну. Він вийде з ладу майже миттєво і запропонують запустити діагностичний інструмент. Завантажте інструмент і дозвольте йому запуститися.

5. Інструмент знайде та виправить деякі проблеми. На цьому етапі знову запустіть оновлення Windows вручну. На даний момент оновлення Windows нормально працювало.

Я знайшов цю чудову відповідь тут, і вона прекрасно працювала для мене. Просто хочу поділитися, якщо хтось шукає:

Спробуйте це у підвищеному командному рядку:

netsh winhttp import proxy source=ie

і перезавантажити

Ще одне рішення, яке працювало для мене, - встановити режим оновлення на "Ніколи не перевіряти наявність оновлень"

Я використовував інструмент готовності до оновлення системи та DISM. Це працювало для мене. Ви можете отримати його тут: http://support.microsoft.com/kB/947821

Я грав з VM 2012 року, і у мене виникла ця проблема. Моє рішення (швидке, незахищене і т. Д.) Було відключити захищений IE на сервері, і він із задоволенням почав спілкуватися з MS Windows Update. Не рішення для реального сервера, але це іграшковий сервер розробників, і я з цим все в порядку.

Імовірно, сайт оновлення Windows просто потрібно десь додати до надійних сайтів, щоб отримати справжнє рішення?

Моє виправлення на нещодавно встановленому на Windows Server 2012 R2 на Citrix 6.5 VM, і як Маркус Грізлі опублікував, відключити IE Enchanced Security ... працював негайно ...

Щоб вимкнути розширену безпеку IE у Windows Server 2012 R2, запустіть диспетчер серверів, ліворуч натисніть на локальний сервер. Праворуч натисніть на посилання біля поруч із налаштуваннями безпеки IE. Тепер ви побачите поле Розширена настройка безпеки Internet Explorer.

https://prajwaldesai.com/disable-ie-enhanced-security-in-windows-server-2012-r2/

Нещодавно у мене на сервері 2012 були ті самі проблеми, і я лише відключив службу Malwarebytes та оновлення, завантажені відразу. Спробуйте вимкнути будь-яке зловмисне або антивірусне програмне забезпечення, оскільки це може бути причиною.

Огляд

Ми мали цю проблему на деяких віртуальних серверах, переміщених від "хмарного" постачальника назад до нашого внутрішнього центру обробки даних. Першопричиною були дозволи на %SystemRoot%\System32\catroot2папку. Існує ряд відмінностей між дозволами на цю папку на здоровому сервері та тими, що на перенесеному сервері. Я вважаю, що ключовим було те, TrustedInstallerчого не було full access.

Додаткові симптоми

Переглядаючи журнал додатків у переглядачі подій, ми побачили ряд помилок:

Source: CAPI2
EventId: 257
Text: The Cryptographic Services service failed to initialize the Catalog Database. The ESENT error was: -1032.

Source: ESENT
EventId: 490
Text: Catalog Database (416) Catalog Database: An attempt to open the file "C:\Windows\system32\CatRoot2\{127D0A1D-4EF2-11D1-8608-00C04FC295EE}\catdb" for read / write access failed with system error 5 (0x00000005): "Access is denied. ".  The open file operation will fail with error -1032 (0xfffffbf8).

Підказка міститься в тексті помилки ESENT; тобто дозволи видавати доступ до файлу в папці catroot2.

Дозвіл

Надайте повний контроль обліковому запису Trusted Installer папці catroot2 та її дітям.

У випадку, якщо цього недостатньо, для порівняння, запуск icacls %systemroot%\system32\catroot2на здоровому сервері дає це:

C:\Windows\system32\catroot2 NT SERVICE\CryptSvc:(F)
                         NT SERVICE\CryptSvc:(OI)(CI)(IO)(F)
                         NT SERVICE\TrustedInstaller:(I)(F)
                         NT SERVICE\TrustedInstaller:(I)(CI)(IO)(F)
                         NT AUTHORITY\SYSTEM:(I)(F)
                         NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F)
                         BUILTIN\Administrators:(I)(F)
                         BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
                         BUILTIN\Users:(I)(RX)
                         BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE)
                         CREATOR OWNER:(I)(OI)(CI)(IO)(F)
                         APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(RX)
                         APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(OI)(CI)(IO)(GR,GE)

Примітка. Щоб додати довіреного інсталятора, вам потрібно буде пошукати на локальних комп'ютерних облікових записах nt service\trustedinstaller.

Після заміни дозволів catroot2переконайтесь, що ви натискаєте replace permissions on child objects & containersпрапорець, щоб переконатися, що дочірні елементи також вирішили свої дозволи.

Для самого виправлення не потрібно перезавантажувати (хоча очевидно, щойно оновлення почнуть працювати знову, вам, ймовірно, доведеться перезавантажити їх).