Архив метки: windows

Исправление ошибки TPM 80090016 в Windows

TPM-модуль все чаще используется в странах бывшего СССР в связке с шифрованием дисков при помощи Bitlocker. С его использованием периодически возникают некоторые проблемы, которые на первый взгляд выглядят очень страшно: например, ошибка, которая прямо нам заявляет «Your computer’s Trusted Platform Module has malfunctioned».

Итак, если ваш компьютер/ноутбук входит в AD и вы получили эту ошибку, например, при первоначальной активации офиса или MS Teams — проверьте связь с доменом. Если вы не находитесь в корпоративной сети — подключитесь к корпоративному VPN (у вас же есть такая возможность?) и попробуйте активировать офис снова. Скорее всего это решит вашу проблему.

А вот если такая ошибка выскочила «на пустом месте» при очередном запуске ПО от MS и внезапном запросе авторизации, чего обычно не случается при работе под доменной учеткой — связь с доменом скорее всего не поможет. Если это ваш случай (и TPM-модуль не вышел из строя) — попробуйте зайти на это устройство с другой учеткой с правами локального администратора (предварительно выполнив Logout из проблемной) и переименовать директорию C:\Users\<username>\AppData\Local\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy например в C:\Users\<username>\AppData\Local\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy.old (где <username> — логин учетной записи, в которой наблюдаются проблемы). Затем снова войдите под проблемной учеткой, подключитесь к корпоративной сети и попробуйте залогиниться в офисное приложение — проблема должна исчезнуть.

Миграция dual-boot Windows 7 + Windows 10 на другой HDD с загрузкой по UEFI

После переноса ОС на другой HDD (или SSD) путем клонирования или при помощи «специальных тулов» для миграции, могут возникнуть проблемы с загрузкой Windows 10. В частности, частой проблемой является черный экран после загрузки, на котором виден только курсор. Ожидание не приносит результатов, загрузка в безопасном режиме тоже ничего не решает. Инструмент автоматического решения проблем при загрузке не помогает. При этом первая система (Windows 7) работает отлично и грузится без проблем.

Для «лечения» нам понадобится загрузить компьютер при помощи установочного диска Windows 10, затем:

  • Открыть командную строку;
  • Запустить diskpart;
  • Найти загрузочный раздел при помощи команды list volume и букву системного диска;
  • select volume X (X — загрузочный раздел fat32);
  • assign letter w (назначаем букву, чтобы получить доступ к файлам);
  • exit (выходим из diskpart);
  • bcdboot Y:\Windows /s w: /f UEFI (где Y — буква диска, на котором находится папка Windows);
  • Перезагружаем систему и при загрузке выбираем новый пункт меню (если он появился);
  • Открываем msconfig и удаляем из пунктов загрузки «старую» опцию \Windows, оставляем только C:\Windows для нашей windows 10 и пункт с загрузкой Windows 7 (при наличии).

The application-specific permission settings do not grant Local Activation permission for the COM Server application…

На разных серверах в разное время возникают ошибки вида:

The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID {8D8F4F83-3594-4F07-8369-FC3C3CAE4919}
  and APPID
 {F72671A9-012C-4725-9D2F-2A4D32D65169}
  to the user NT AUTHORITY\SYSTEM SID (S-1-5-18) from address LocalHost (Using LRPC) running in the application container Unavailable SID (Unavailable). This security permission can be modified using the Component Services administrative tool.

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

Итак, для исправления этой ошибки нам необходимо выдать соответствующей учетной записи те права, которых ей не хватает. Для этого надо:
1. Запустить Component services из administrative tools;
2. Перейти по дереву в Component Services -> Computers ->My Computer -> DCOM Config;
3. Кликнуть ПКМ на DCOM Config, выбрать View->Detail;
4. Справа мы увидим список приложений с их Application ID. Список не сортируется и вам придется вручную найти APPID из вашей ошибки. Находим и кликаем по нему ПКМ, заходим в Properties;
5. Переходим на вкладку Security;
6. Выбираем в блоке Launch and Activation Permissions пункт Customize и нажимаем Edit;
7. Добавляем NT AUTHORITY\SYSTEM в список и разрешаем ему Local launch и Local activation;
8. Перезапускаем сервис, использующий этот AppID (или перезагружаем компьютер/сервер). Ошибки должны исчезнуть.

А теперь поговорим о том, что же делать, если на вкладке Security ничего нельзя выбрать (как это и бывает в большинстве случаев), т.е. если все контролы отключены. Для этого запускаем Regedit, дальше:
1. Идем в HKLM\SOFTWARE\Classes\AppID;
2. Находим наш AppID в списке;
3. Кликаем ПКМ, открываем Permissions;
4. Переходим в Advanced;
5. Меняем владельца на свою учетную запись (изначально там TrustedInstaller), в противном случае не сможем поменять свои права;
6. Добавляем себе права на Full Control;
7. Возвращаемся в Component Services и проделываем пункты 1-8;
8. Возвращаем владельца ветки реестра, а для этого указываем в качестве владельца NT service\TrustedInstaller. Если компьютер в домене — не забываем выбрать локальный компьютер в качестве области поиска пользователя.

На этом всё, ошибка не будет больше досаждать.

Файлы cab_xxxx в директории windows\temp

В последнее время начали появляться проблемы со свободным местом на системных дисках на нескольких компьютерах. Свободные 100 Гб медленно но верно исчезали пока пользователи не начинали получать предупреждения о недостатке места на диске. Выяснялось, что все место исчезало благодаря файлам cab_xxxx, где xxxx — 4 цифры. Эти файлы лежали в директории C:\Windows\Temp. Простое удаление файлов освободит место, но не исправит проблему. Единственно верное решение — удалить эти файла,  а также удалить логи из директории C:\Windows\Logs\CBS. Только в таком случае временные файлы перестанут появляться и съедать весь диск.

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

Решение проблемы «The trust relationship between this workstation and the primary domain failed» без вывода ПК из домена

По самым разным причинам можно столкнуться с проблемой невозможности входа в систему на компьютере, включенном в домен. Если это происходит на обычном клиентском ПК — ничего не мешает вывести его из домена и добавить заново — проблема решается гарантированно. Но если дело касается сервера, на котором крутятся приложения, завязанные на AD — рисковать выводом сервера из домена не очень хочется. К счатью, способ «возврата» к нормальному состоянию есть.

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

 This computer could not authenticate with DomainController’ a Windows domain controller for domain DOMAIN, and therefore this computer might deny logon requests. This inability to authenticate might be caused by another computer on the same network using the same name or the password for this computer account is not recognized. If this message appears again, contact your system administrator.

Т.е., как обычно у майкрософта, ничего конкретного о способах решения в ошибке не сказано. Корни проблемы уходят в доменную авторизацию: по умолчанию, пароль для учетной записи компьютера имеет срок жизни в 30 дней. Если ОС не связывалась с доменом в течение этого срока или, например, вы восстановили из бэкапа 30-дневной давности сервер/виртуалку — вы не сможете залогиниться на него под доменной учетной записью. Для исправления этой ситуации необходимо:

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

2. Выполнить команду klist purge для очистки кэша Kerberos на сервере.

3. Выполнить команду  «netdom resetpwd /s:x.x.x.x  /ud:domain\User /pd:*», где x.x.x.x — IP-адрес контроллера домена, domain\User — учетная запись администратора домена с указанием имени домена.

4. После запроса пароля — ввести пароль от учетной записи администратора домена.

5. Перезагрузить сервер и залогиниться под учетной записью администратора домена.

Если это не помогло — вам поможет только вывод компьютера из домена и повторное его туда включение. Или техподдержка Майкрософта :)