Код ошибки возвращенный модулем шифрования 0x8009030d

Содержание

Проблемы при миграции виртуальной машины Hyper-V в Windows Server 2012 R2 (0x8009030E, 0x8009030D и др.)

Всем привет сегодня разберем, как решается ошибка 0x8009030E или 0x8009030D при миграции виртуальной машины Hyper-V в Windows Server 2012 R2. Напомню миграция — это перемещение виртуальной машины на другой хост виртуализации, и вот во время этого процесса возникает этот неприятный момент.

Сбой операции миграции виртуальной машины в исходном расположении миграции

Причины ошибок 0x8009030E и 0x8009030D

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

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

Решения:

На вкладке Динамическая миграция, должна стоять галка Включить входящие и исходящие миграции.

Вторая причина у вас не включен Kerberos. Если у вас по CredSSp, не удается мигрировать выставляем тогда Kerberos, для большей безопасности, его мы еще поднастроим.

Так же если вы пытаетесь делать миграцию работающей виртуальной машины, может возникнуть ошибка VMM:

virtual machine … is using processor-specific features not supported on host…

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

Если вы выполняете миграцию с рабочей станции, через оснастку Диспетчер Heper-V вы опять словите данную ошибку 0x8009030E или 0x8009030D, так как данную операцию нужно производить с хоста Hyper-V, где лежит тачка подключенного по RDP, но не спешите расстраиваться, мы же не зря настраивали kerberos, делаем ниже инструкции и радуемся жизни

Для того чтобы kerberos отработал и вы не получили ни 0x8009030E, ни 0x8009030D при миграции виртуальной машины Hyper-V в Windows Server 2012 R2, делаем следующее. Открываем оснастку Active Directory — Пользователи и компьютеры, ищем там ваши компьютеры Hyper-V и переходим в их свойства. Переходим на вкладку Делегирование, выставляем там Доверять компьютеру делегирование указанных служб > Использовать только Kerberos и добавляем туда две службы первая — cifs (для миграции хранилищ), вторая — Microsoft Virtual System Migration Service

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

Все можно теперь мигрировать спокойно.

Если у вас SCVMM

Если у вас есть scvmm, то проверьте, что в свойствах хоста

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

0x8009030E при миграции виртуальной машины Hyper-V в Windows Server 2012 R2

Всем привет сегодня разберем, как решается ошибка 0x8009030E при миграции виртуальной машины Hyper-V в Windows Server 2012 R2. Напомню миграция — это перемещение виртуальной машины на другой хост виртуализации, и вот во время этого процесса возникает этот неприятный момент.

Причины ошибки 0x8009030E

Первая причина у вас не включена динамическая миграция Hyper-V, проверить это можно в свойствах хоста виртуализации.

На вкладке Динамическая миграция, должна стоять галка Включить входящие и исходящие миграции.

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

Для того чтобы kerberos отработал и вы не получили 0x8009030E при миграции виртуальной машины Hyper-V в Windows Server 2012 R2, делаем следующее. Открываем оснастку Active Directory — Пользователи и компьютеры, ищем там ваши компьютеры Hyper-V и переходим в их свойства. Перехлдим на вкладку Делегирование, выставляем там Доверять компьютеру делегирование указанных служб > Использовать только Kerberos и добавляем туда две службы первая — cifs (для миграции хранилищ), вторая — Microsoft Virtual System Migration Service

Все можно теперь мигрировать спокойно.

Если у вас SCVMM

Если у вас есть scvmm, то проверьте, что в свойствах хоста

Мигрируем через Powershell

Думаю было не сложно и вы победили свою ошибку 0x8009030E.

13 марта Microsoft опубликовал описание уязвимости CVE-2018-0886 в протоколе проверки подлинности CredSSP, который в частности используется при подключении по RDP к терминальным серверам. Позже Microsoft опубликовал, что будет блокировать подключения к необновлённым серверам, где присутствует данная уязвимость. В связи с чем многие заказчики столкнулись с проблемами подключения по RDP.

В частности, в Windows 7 можно увидеть ошибку: "Произошла ошибка проверки подлинности. Указанная функция не поддерживается"

В Windows 10 ошибка расписана более подробно, в частности сказано "Причиной ошибки может быть исправление шифрования CredSSP":

Для обхода ошибки со стороны клиента многие советуют отключить групповую политику, путём установки значения Encryption Oracle Remediation в Vulnerable:
с помощью gpedit. msc в Конфигурация компьютера / Административные шаблоны / Система / Передача учётных данных, слева выбрать "Исправление уязвимости шифрующего оракула" (забавный конечно перевод), в настройках поставить "Включено" и выбрать "Оставить уязвимость".

или через реестр (т. к., например, в Windows Home нет команды gpedit. msc):

REG ADD HKLMSoftwareMicrosoftWindowsCurrentVersionPoliciesSystemCredSSPParameters /v AllowEncryptionOracle /t REG_DWORD /d 2

НО! Так делать не нужно! Т. к. таким образом вы оставляете уязвимость и риски перехвата вашего трафика и пр. конфиденциальные данные, включая пароли. Единственный случай, когда это может быть необходимо, это когда у вас вообще нет другой возможности подключиться к удалённому серверу, кроме как по RDP, чтобы установить обновления (хотя у любого облачного провайдера должна быть возможность подключения к консоли сервера). Сразу после установки обновлений, политики нужно вернуть в исходное состояние.

Если доступ к удалённому серверу есть, то ещё, как временная мера, можно отключить требование NLA (Network Level Authentication), и сервер перестанет использовать CredSSP. Для этого достаточно в Свойствах системы, на вкладке удалённые подключения снять соответствующую галку "Разрешить подключения только с компьютеров, на которых работает удалённый рабочий стол с проверкой подлинности на уровне сети":

Но, это тоже неправильный подход.

Правильный подход — это всего-лишь установить нужные обновления на операционную систему, закрывающие уязвимость CVE-2018-0886 в CredSSP, причём, как серверную, куда вы подключаетесь, так и клиентскую, с которой вы подключаетесь.

Произошла неустранимая ошибка при попытке обращения к закрытому ключу учетных данных SSL server. Код ошибки, возвращенный модулем шифрования: 0x8009030d. Внутреннее состояние ошибки: 10001.

0x8009030E при миграции виртуальной машины Hyper-V в Windows Server 2012 R2

Причины ошибки 0x8009030E

На вкладке Динамическая миграция, должна стоять галка Включить входящие и исходящие миграции.

Все можно теперь мигрировать спокойно.

Если у вас SCVMM

Если у вас есть scvmm, то проверьте, что в свойствах хоста

Мигрируем через Powershell

Думаю было не сложно и вы победили свою ошибку 0x8009030E.

Вопрос

36870
0
2
0
0
0x8000000000000000

server
0x8009030d
10001

Ответы

На сертификаты. Надо в выводе команды опознать сетрификат «SSL Server» (по отпечатку, по серийному номеру — смотрите свойства этого сертификата) и посмотреть для него имя контейнера ключа.

Все ответы

Недоступен закрытый ключ сертификата. Причины могут быть разные. Одна из наиболее частых — отсутствие разрешений у учетной записи, которая должна использовать сертификат (Local System (Система) в данном случае — см. элмент в XML события)

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

и, после этого, проверьте, и, если надо, — добавьте разрешение на чтение на файл с этим именем в папке

C:ProgramDataMicrosoftCryproRSAMachineKeys (для поставщика RSA) или C:ProgramDataMicrosoftCryproKeys (для CNG)

для учетной записи Local System (Система).

А на что при выводе команды нужно обратить внимание?

Заметил еще 2 нюанса:

1) Ошибка возникает только в момент подключения через «Подключение к удаленному рабочему столу» к данному компьютеру.

2) На компьютере подключенному к домену такой ошибки не возникает.

Проблема актуальна и сейчас, а потому напишу своё решение, которое мне помогло (вдруг кто будет искать, и наткнётся на тему)

Ошибки сыпятся из-за включения шифрования SSLдля RDP-соединения. И не всегда это происходит из-за ручного вмешательства. У меня появилось после массового обновления с Центра обновлений Windows на двух серверах Server 2008r2 с ролями Lync 2013.

Вылечилось путём отключения шифрования:

Заходите Администрирование — Службы удаленных рабочих столов, откройте Конфигурация узла сеансов удаленных рабочих столов. Щёлкаете по значку RDP-TCP и меняете Уровень шифрования на совместимый с клиентом. У меня стояло FIPS-совместимый:

Ошибки сразу пропадают, и RDP-соединения начнут работать.

Код ошибки 0x80004005 в Windows 10

Печальный код ошибки 0x80004005 в Windows 10 может появляться в нескольких вариациях, и в основном классифицируется как «Неопределенная ошибка», что затрудняет понять источник возникновения данной ошибки. Ошибка 0x80004005 может возникать, когда пользователь не может получить доступ к общим папкам или дискам по сети, виртуальным машинам, как Virtual Box. Но это не все, эта ошибка также появляется при установки обновлений Windows в «центре обновления». Давайте посмотрим, как исправить код ошибки 0x80004005 в Windows 10.

Как исправить ошибку 0x80004005 в Windows 10

Я буду приводить решение данной ошибки для различных ситуаций, будь то ошибка в Virtual box, ошибка сети доступа или в центре обновления Windows. Вы можете сразу выбрать, где у вас ошибка и приступить к исправлению:

1. Ошибка 0x80004005 при попытке доступа к общим папкам и дискам

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

Способ 1. Нажмите сочетание кнопок Win + R и введите regedit, чтобы открыть редактор реестра. В редакторе реестра перейдите по следующему пути:

Нажмите справа на пустом поле правой кнопкой мыши и «Создать» > «Параметр DWORD (32 бита)«. Далее задайте имя LocalAccountTokenFilterPolicy и значение 1. Если у вас система 64-bit, то нужно создать параметр QWORD (64 бита).

Способ 2.

Нажмите сочетание кнопок Win + R и введите hdwwiz. cpl, чтобы открыть диспетчер устройств. Далее разверните графу «Сетевые адаптеры«, нажмите на вкладку сверху «Вид» и выберите «Показать скрытые устройства«. Если у вас появятся сетевые адаптеры Microsoft 6to4, то щелкните по ним правой кнопкой мыши и выберите удалить устройство. Перезагрузите ПК и проверьте устранена ли ошибка 0x80004005 при сетевом доступе.

Если ошибка не усnранена, то рекомендую проверить SMB протокол. Обратитесь к этому руководству Шаг 6.

2. Ошибка E_FAIL (0x80004005) Virtual Box

Способ 1. Нажмите сочетание кнопок Win + R и введите regedit, чтобы открыть редактор реестра. В редакторе реестра перейдите по следующему пути:

Если справа у вас есть подобный ключ C:Program FilesOracleVirtualBoxVirtualBox. exe со значением DisableUserCallbackException, то удалите его и проверьте решена ли проблема. Если вы используете антивирусный продукт, то отключите его на время и повторите момент с реестром.

Способ 2. Нужно попробовать переименовать файлы, тем самым задействовать файл-бэкап копии. Для начало вы должны знать путь установленной системы при которой вылетает ошибка. Путь можно посмотреть в самом Virtual Box нажав на «Файл» > «Настройки». Когда узнали путь переходим по нему, по умолчанию у всех он C:Usersваше имяVirtualBox VMs выбираем ОС, в мое случае это папка 7 (Win7). В папке нас интересуют два файла с расширением .vbox и .vbox-prev:

Теперь перейдите в папку C:Usersваше имя. VirtualBox, нужно проделать тоже самое:

3. Ошибка 0x80004005 Центра обновления Windows

Разберем, как исправить ошибку 0x80004005 в Windows 10 при установке обновлений.

Способ 2. Если это не обновление функции, а только накопительное обновление, вы можете вручную скачать и установить обновления Windows из официального каталога Microsoft. Откройте «Параметры» > «Обновление и безопасность» > «Центр обновления Windows» > справа «Просмотр журнала обновлений«. Посмотрите в журнале, какое именно обновление не удалось. Далее перейдите в каталог обновлений Windows введите номер KB обновления, которое не удалось установить, скачайте его и установите.

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

Указан неправильный алгоритм (0х80090008)

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

сертификат проверьте и список всего ПО с версиями сюды

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

makariesp пишет: Ошибка создания подписи: указан неправильный алгоритм (0х80090008).

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

makariesp пишет: Алгоритма у казанного в теме «КонтинентАП 0x80090008 указан неверный алгоритм» нет.

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

makariesp пишет: Я не программист

Нет параметра:
[HKEY_LOCAL_MACHINESOFTWAREMicrosoftCryptographyOIDEncodingType 0CryptDllFindOIDInfo-1.2.643.2.1.3.1.2.1!3].
Есть:
[HKEY_LOCAL_MACHINESOFTWAREMicrosoftCryptographyOIDEncodingType 0CryptDllFindOIDInfo-1.2.643.2.1.3.1.2.1!4].

Вот и первый успех — докопались-таки до нужных веток реестра!
1. «Родной» параметр в HKEY_LOCAL_MACHINESOFTWAREMicrosoftCryptographyOIDEncodingType 0CryptDllFindOIDInfo — это 1.2.643.2.1.3.1.2.1!3 (без»-» впереди).
2. Кто-то или по ошибке, или почему уже переименовал другой параметр в «-1.2.643.2.1.3.1.2.1! 4 ], зачем — не знаю, но он сейчас нас не интересует.
3. Если в ветке HKEY_LOCAL_MACHINESOFTWAREMicrosoftCryptographyO >3 «, которую и надо переименовать в » — 1.2.643.2.1.3.1.2.1!3″ — больше не знаю что ещё можно подсказать для решения проблемы, к сожалению. Возможно более опытные коллеги помогут Вам.

Источники:

https://adminotes. ru/problemy-pri-migratsii-virtualnoj-mashiny-hyper-v-v-windows-server-2012-r2-0x8009030e-0x8009030d-i-dr/

https://zoo-tortila. ru/kod-oshibki-vozvrashhennyj-modulem-shifrovanija/

https://top-office11.ru/oshibki-i-problemy/kod-oshibki-vozvrashhennyj-modulem-shifrovaniya-0x8009030d. html