capi2 что это microsoft windows

Event ID 4107 или Event ID 11 регистрируется в журнале приложения

В этой статье предусмотрены действия по решению события 4107 и события 11, которые вошли в журнал приложения.

Применяется к: Windows Server 2012 R2, Windows 2008 R2 Пакет обновления 1, Windows 7 Пакет обновления 1
Исходный номер КБ: 2328240

Симптомы

В журнале приложения регистрируются следующие сообщения об ошибках:

Причина

Эта ошибка возникает из-за истечения срока действия Publisher сертификата Microsoft Certificate Trust List. Копия CTL с истекшим сертификатом подписи существует в папке CryptnetUrlCache.

Решение

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

Откройте окно командной строки. Выберите Начните, выберите все программы, выберите аксессуары, а затем выберите командную подсказку.

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

Команда certutil должна запускаться для каждого пользователя на рабочей станции. Каждый пользователь должен войти и следовать шагам 1 и 2 выше.

Если истек сертификат кэшировали в одном из локальных системных профилей, необходимо удалить содержимое некоторых каталогов с помощью Windows Explorer. Для этого выполните следующие действия:

Откройте проводник. Выберите Начните, выберите все программы, выберите аксессуары, а затем выберите Windows Explorer.

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

Удалите содержимое каталогов, перечисленных здесь. (%windir% — это Windows каталога.)

Вы можете получить сообщение о том, что у вас нет разрешения на доступ к папке. Если вы получили это сообщение, выберите Продолжить.

LocalService :
%windir%\ServiceProfiles\LocalService\AppData\LocalLow\Microsoft\CryptnetUrlCache\Content
%windir%\ServiceProfiles\LocalService\AppData\LocalLow\Microsoft\CryptnetUrlCache\MetaData

NetworkService :
%windir%\ServiceProfiles\NetworkService\AppData\LocalLow\Microsoft\CryptnetUrlCache\Content
%windir%\ServiceProfiles\NetworkService\AppData\LocalLow\Microsoft\CryptnetUrlCache\MetaData

LocalSystem :
%windir%\System32\config\systemprofile\AppData\LocalLow\Microsoft\CryptnetUrlCache\Content
%windir%\System32\config\systemprofile\AppData\LocalLow\Microsoft\CryptnetUrlCache\MetaData

Дополнительная информация

Event ID 4107 также может быть в журнале с данными является недействительной ошибкой, а не следующей ошибкой:

Необходимый сертификат не находится в пределах срока действия при проверке на текущих системных часах или времени в подписаном файле.

Эта ошибка Data является недействительной, указывает на то, что объект, возвращенный из сети, не был допустимым файлом кабины. Поэтому Windows не удалось правильно его разсмеять. Случаи такой ошибки могут возникать, когда попытка сетевого ибора для файла кабины не проходит через прокси. Если прокси-сервер возвращает некоторые данные или сообщение вместо стандартного кода ошибки HTTP, Windows будет пытаться разбор сообщения, полученного от прокси, ожидая, что это будет кабина. Эта ситуация не удастся с данными является недействительной ошибкой.

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

Источник

Описание и причины ошибки ID 513

Делая ревизию серверов на базе Windows Server 2019, я обнаружил ошибку, ее содержимое было вот таким:

Найти все это можно в журнале «Приложения (Application)».

Если обратиться по данной ошибке на Microsoft, то там дано вот такое пояснение причины:

Во время резервного копирования процесс VSS, запущенный под учетной записью NETWORK\SERVICE, вызывает cryptcatsvc!CSystemWriter::AddLegacyDriverFiles(), который перечисляет все записи драйверов в базе данных Service Control Manager и пытается открыть каждую из них. Функция не имеет прав на запись драйвера Microsoft Link-Layer Discovery Protocol (Mslldp.dll) и падает с ошибкой «Доступ запрещен». Оказалось, что разрешения безопасности драйвера MSLLDP не позволяют NETWORK\SERVICE получить доступ к записи драйвера.

Как устранить ошибку ID 513 CAPI2

Логично предположить, что нам нужно добавить прав, в этом нам с вами помогут две утилиты sc и accesschk64. Для начала давайте проверим. что не хватает прав у учетной записи NT AUTHORITY\SERVICE, для этого вам нужно скачать утилиту accesschk64, которая входит в состав пакета Sysinternals. Для начала мы с помощью данной утилиты посмотрим текущие разрешения для двух библиотек и сравним их:

Для этого нам потребуется запустить командную строку из папки, где у вас лежит утилита accesschk64 и выполнить вот такие команды:

Следующим шагом нам нужно внести изменения в список доступа на библиотеке mslldp. Для этого нам нужно воспользоваться утилитой SC и посмотреть правильное значение. Находясь в командной строке введите команду:

Я выделил желтым значение (A;;CCLCSWLOCRRC;;;SU) именно оно и дает права чтения для NT AUTHORITY\SERVICE. Убедитесь, что в библиотеке mslldp, данное значение отсутствует:

Далее нам нужно добавить значение (A;;CCLCSWLOCRRC;;;SU) в список доступа, для этого скопируйте всю строчку с выводом для библиотеки mslldp и добавьте в самом конце недостающее значение. После чего выполните команду:

Теперь снова проверим права на доступ к библиотекеmslldp.dll

Источник

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

Для начала, на что нужно обратить внимание, это на то, что в групповых политиках, применяемых к компьютерам, не должен быть задействован параметр блокирующий работу механизма авто-обновления. Это параметр Turn off Automatic Root Certificates Update в разделе Computer Configuration > Administrative Templates > System > Internet Communication Management > Internet Communication settings. Нам потребуется, чтобы этот параметр был Выключен, либо просто Не настроен.

Если взглянуть на хранилище сертификатов TrustedRootCA в разделе Локальный компьютер, то на системах, не имеющих прямого доступа в Интернет, набор сертификатов будет прямо так скажем небольшой:

Но вариант прямого доступа в рамках данной заметки мы больше упоминать не станем и рассмотрим пример локализации процесса обновления в соответствии с ранее упомянутой статьёй.

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

Попробуем на компьютере имеющем прямое подключение к Интернету выполнить команду генерации SST файла, который будет в себе содержать актуальный набор файлов корневых сертификатов. В данном случае на компьютере с Windows 10 выполняется команда, вызывающая входящую в базовый состав ОС утилиту Certutil, которая в свою очередь обращается к веб-узлу Microsoft и создаёт по указанному нами пути SST файл:

Полученный в результате выполнения команды SST-файл по сути является контейнером, который содержит в себе все сертификаты для нужного нам обновления системы. Этот контейнер легко открывается в Проводнике Windows загружая ассоциированную с расширением файла оснастку управления сертификатами.

Этот файл удобно использовать, например, когда из всего подмножества доступных сертификатов нужно выбрать лишь некоторый набор и выгрузить их в отдельный SST файл для дальнейшей загрузки, например, с помощью консоли управления локальными сертификатами или с помощью консоли управления групповыми политиками (для импорта в какую-либо доменную политику через параметр Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities).

Однако для интересующего нас способа распространения корневых сертификатов, с помощью модификации работы механизма авто-обновления на конечных клиентских компьютерах, нам потребуется несколько иное представление множества актуальных корневых сертификатов. Получить его можно с помощью всё той же утилиты Certutil, но уже с другим набором ключей.

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

В результате выполнения команды в указанной нами сетевой папке появится множество файлов общим объемом примерно в пол мегабайта:

Скопируем этот файл на контроллер домена в каталог %SystemRoot%\inf (как правило, это каталог C:\Windows\inf ). После этого перейдём в редактор доменных групповых политик и создадим отдельную новую политику, открыв затем её на редактирование. В разделе Computer Configuration > Administrative Templates… откроем контекстное меню и выберем пункт подключения нового шаблона политик Add/Remove Templates

После проделанного действия в разделе Configuration > Administrative Templates > Classic Administrative Templates (ADM) появится группа Windows AutoUpdate Settings, в которой будет доступен единственный параметр URL address to be used instead of default ctldl.windowsupdate.com

Сохраним проделанные изменения и применим созданную политику к доменному контейнеру, в котором расположены целевые компьютеры. Однако рассмотренный метод настройки GPO имеет ряд недостатков и именно поэтому я назвал его «олд-скульным».

При необходимости можем для созданного параметра GPP включить гибкий механизм нацеливания (Закладка Common > Опция Item-level targeting) на конкретный компьютер или группу компьютеров для предварительного тестирования того, что у нас в конечном итоге получиться после применения групповых политик.

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

Для примера посмотрим, есть ли в хранилище сертификатов компьютера корневой сертификат, использованный для выпуска сертификата, который установлен на сайте с именем buypass.no (но на сам сайт пока не переходим :)).

Сделать это удобнее всего с помощью средств PowerShell:

После этого мы можем снова выполнить указанную ранее команду запроса к хранилищу корневых сертификатов и увидим, что теперь в нём действительно появился новый корневой сертификат, именно тот который фигурировал в событии event-лога Windows:

Как видим, механизм авто-обновления работает и теперь всё, что остаётся, это организовать поддержку в актуальном состоянии файлов в сетевой папке, запланировав, например на ночное время, ежесуточное выполнение задания обновления ранее упомянутой командой:

Дополнительные источники информации:

Источник

Исправляем ошибки установки обновлений Windows 7

Windows 7 по-прежнему остается популярной операционной системой в корпоративной среде, несмотря на то, что уже вышли две новые версии клиентских ОС. Расширенная поддержка «семёрки» закончится лишь 14 января 2020 г., а это значит, что ближайшие 4 года для нее будут выходить обновления, исправляющие обнаруженные уязвимости.

Существует правило – если есть обновления, то есть и проблемы с их установкой. Давайте разберем, какие основные проблемы возникают при обновлении Windows 7 через Windows Server Update Services (WSUS) и как их исправить с наименьшими затратами.

Ошибка #1. Failed to find updates with error code 80244010

Эту ошибку вы практически гарантированно будете наблюдать на любой системе, впервые обратившейся к серверу WSUS. В WindowsUpdate.log также встретится предупреждение:
WARNING: Exceeded max server round trips

Причина проблемы в том, что список обновлений стал слишком большим, и клиент не может принять его за один заход. Подробности — blogs.technet.microsoft.com/sus/2008/09/18/wsus-clients-fail-with-warning-syncserverupdatesinternal-failed-0x80244010
Какое решение предлагает Microsoft? Если после ошибки запустить повторный поиск обновлений, то процесс загрузки метаданных продолжится с момента возникновения ошибки. Терпение господа, терпение. Три, пять попыток wuauclt /detectnow – и все образуется. Не забудьте при повторном поиске дождаться окончания предыдущего цикла поиска, иначе магия не сработает!

Ошибка #2. Не устанавливаются обновления Windows с ошибкой 0x80070308

Встречается эпизодически, и в одном случае из 100 у нее есть единственное и очень специфическое решение — удалить ключ
HKLM\Components\PendingRequired=1

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

Ошибка #3. Все другие ошибки

Summary:
Seconds executed: 1164
Found 16 errors
Fixed 4 errors

Проблема заключается в том, что во время установки обновлений в системе могут появиться битые файлы. Что является причиной — неисправная сеть, диск, оперативная память, сам Windows Update – выяснить не получится, а исправить ошибки для установки последующих обновлений придется.

Как правило, повреждаются *.cat, *.mum, *.manifest файлы. У кого-то повреждаются *.dll, но я на практике не сталкивался. И вроде бы средство SURT должно само исправить ошибки, поскольку внутри него есть огромный каталог эталонных файлов. Только в последний раз SURT обновлялся в октябре 2014 года, а исправлений на операционную систему с тех пор вышло бесчисленное множество, и многих файлов в каталоге не хватает.

Ниже я опишу последовательность действий, необходимых для исправления ошибок установки обновлений на Windows 7 x64 с использованием SURT. Для редакции x86 просто потребуется другой пакет SURT из KB947821.

Последовательность действий будет следующая.

1. Запустить первый проход Windows6.1-KB947821-v34-x64.msu

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

где BUHWKS02 – целевая машина.
Когда скрипт отработает и встанет на паузу, проверяем %windir%\Logs\CBS\CheckSUR.log
Если ошибок не найдено – дело не в битых обновлениях.
Если он заканчивается

Summary:
Seconds executed: 1164
Found 16 errors
Fixed 4 errors
CSI Manifest All Zeros Total count: 6
CSI Catalog Corrupt Total count: 3
Fixed: CSI Catalog Corrupt. Total count: 3
CBS MUM Corrupt Total count: 3
CBS Catalog Corrupt Total count: 3
CSI Catalog Thumbprint Invalid Total count: 1
Fixed: CSI Catalog Thumbprint Invalid. Total count: 1
Unavailable repair files:
winsxs\manifests\wow64_microsoft-windows-gdi32_31bf3856ad364e35_6.1.7601.19091_none_c19fa2719495aca9.manifest
winsxs\manifests\amd64_microsoft-windows-capi2-weakcrypto_31bf3856ad364e35_6.1.7601.23290_none_5e936c9c5ce2e8e6.manifest
winsxs\manifests\wow64_microsoft-windows-gdi32_31bf3856ad364e35_6.1.7601.23290_none_c22840d8adb43043.manifest
winsxs\manifests\amd64_microsoft-windows-gdi32_31bf3856ad364e35_6.1.7601.19091_none_b74af81f6034eaae.manifest
winsxs\manifests\amd64_microsoft-windows-capi2-weakcrypto_31bf3856ad364e35_6.1.7601.19091_none_5e0ace3543c4654c.manifest
winsxs\manifests\amd64_microsoft-windows-gdi32_31bf3856ad364e35_6.1.7601.23290_none_b7d3968679536e48.manifest
servicing\packages\Package_2_for_KB3123479

то будем исправлять.

2. Копируем эталонные файлы на целевую машину

Microsoft предлагает нам длинную, путанную процедуру с извлечением хороших файлов из обновлений и размещением их в определенные каталоги средства SURT. При этом пути в статьях неверные. Где-то и вовсе рекомендуют подкладывать оригинальные msu файлы.

Самый простой и правильный вариант следующий — скопировать эталонные файлы с рабочей системы:

*.mum and *.cat из C:\Windows\servicing\Packages складываются в %windir%\Temp\CheckSUR\servicing\packages
*.manifest из C:\Windows\winsxs\Manifests складываются в %windir%\Temp\CheckSUR\winsxs\manifests\

Проблема в том, что битых файлов обычно десятки, и их очень сложно выбрать и скопировать. Тогда на помощь приходит следующий скрипт PowerShell (эталонной считается машина, с которой вы запускаете скрипт)

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

3. Запускаем второй проход Windows6.1-KB947821-v34-x64.msu

=================================
Checking System Update Readiness.
Binary Version 6.1.7601.22471
Package Version 26.0
2016-03-03 09:15
Checking Windows Servicing Packages
Checking Package Manifests and Catalogs
Checking Package Watchlist
Checking Component Watchlist
Checking Packages
Checking Component Store
Summary:
Seconds executed: 1435
No errors detected

Ошибка #4. Если SURT отработал нормально, а обновления все равно не ставятся

Попробуйте прибегнуть к старому приему – сбросить службу Windows Update в исходное состояние. Для этого необходимо удалить каталог %windir%\SoftwareDistribution.

Ошибка #5

Клиент исчезает из консоли WSUS. Любопытная ошибка, связанная с неправильным клонированием машин и задвоением (затроением и т.д.) идентификаторов клиентов. Решается так:

Ошибка #6

GetCookie failure, error = 0x8024400D, soap client error = 7, soap error code = 300, HTTP status code = 200
SyncUpdates failure, error = 0x80072EE2, soap client error = 5, soap error code = 0, HTTP status code = 200
Windows Update Client failed to detect with error 0x80072ee2

Ошибка связана с нехваткой ресурсов в AppPool WSUS. Решение — снять лимит на потребляемую память. Как это сделать — статья.
Коротко: Открываем IIS, Application Pools, WsusPool, Advanced Settings.
Параметр Private Memory Limit устанавливаем в 0.

Продолжение темы настройки WSUS — в моей следующей статье: https://habrahabr.ru/post/329440/

PS:
Многие ошибки решены в новом клиенте WSUS:
1. KB3125574 «Windows 7 post SP1 Convenience Rollup Update». Внимательно ознакомьтесь с разделом Known issues!

Предварительно необходимо установить KB3020369 «April 2015 servicing stack update for Windows 7 and Windows Server 2008 R2».

Источник