Архив рубрики: Windows

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

Windows, ,

После переноса ОС на другой 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…

registry, Windows, ,

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

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. Если компьютер в домене — не забываем выбрать локальный компьютер в качестве области поиска пользователя.

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

Ошибка STOP 0x0000009E на узле кластера Exchange

Exchange 2010, ,

Жил-был обычный кластер Exchange 2010 и, после некоторого роста количества баз в Database Availability Group, один из двух DB-серверов внезапно начал падать с синим экраном и ошибкой 0x0000009E по ночам аккурат во время бэкапа. Но не всегда. Конечно же, он сразу перезагружался и к утру был в строю, но бэкап-то прерывался…

Поиск возможных причин падения показал, что все не так просто. За время существования ОС Windows обязательных и необязательных апдейтов, которые фиксят эту ошибку вышло достаточно, но дальнейшее изучение показало, что все эти апдейты уже установлены. А сервер продолжает падать с завидной регулярностью.

Проверили версии драйверов, статус рэйда, наличие каких-нибудь системных ошибок — все чисто. Сервера по железу одинаковые, но один падает, а другой продолжает работать. Выбрали в качестве «активного» сервера для баз второй — и падать начал он, а второй тем временем прекрасно работал!

Начали тщательно изучать все графики заббикса и увидели, что в момент начала бэкапа среднее время ответа дисковой подсистемы резко вырастает до 6000 мс (я не ошибся с нулями), затем данные от заббикс-агента отсутствуют, а затем, спустя минут 20-30 происходит ребут. В общем, было видно, что после роста количества (но не размера) баз дисковая подсистема перестала справляться с нагрузкой. Но причем тут синий экран?

Ответ кроется в логике работы Cluster Service: если на определенном этапе сервис перестает отвечать на время, превышающее 60 секунд (по умолчанию), то система выпадает в синий экран и перезагружается, предполагая, что с кластером что-то не то и эта нода не живая. За таймаут и действие по умолчанию отвечают два параметра: ClusSvcHangTimeout и HangRecoveryAction. Просмотреть текущие значения этих параметров можно при помощи команды:

cluster /cluster:clustername /prop

Установить таймаут можно командой:

cluster /cluster:clustername /prop ClusSvcHangTimeout=x

где x — время в секундах.

Но мы решили временно, до апгрейда серверов, установить другое действие по умолчанию, а именно «Запись в лог». Делается это так:

cluster /cluster:clustername /prop HangRecoveryAction=x

В данном случае x может быть от 0 до 3: 0 — отключить мониторинг и не делать вообще ничего, 1 — записать в лог, 2 — остановить Cluster Service, 3 — вызвать «синий экран смерти» с ошибкой 0x0000009E

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

Не работает смена истекшего пароля в OWA Exchange 2010

Exchange 2010,

Функционал по смене пароля в Outlook Web App бывает полезным во многих случаях. Например: у вас истек срок действия пароля от рабочей учетной записи, а в офис вы попасть в ближайшее время не сможете, но почту читать и отправлять надо. В нормальных условиях, если это было разрешено, OWA предлагает сменить пароль для учетной записи при авторизации. Однако, установка Rollup 25 на Exchange 2010 sp3 ломает эту возможность. Вместо диалога по смене пароля вы получаете ответ «неправильное имя пользователя или пароль». Можно, конечно, откатить апдейт, но обычно это не самый удобный вариант.

Для исправления этого косяка надо:
1. Открыть IIS на сервере, который обслуживает OWA.
2. Перейти в Default Web Site.
3. В правой панели кликнуть дважды на Modules.
4. В панели действий (Actions) нажать Configure native modules.
5. Выбрать exppw и нажать OK.
6. После этого сделать iisreset и проверить. Возможность смены пароля должна появиться.

Невозможно войти в скайп. There was an issue looking up your account

Skype

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

There was an issue looking up your account. Tap Next to try again

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

  1. Выгружаем скайп.
  2. Открываем Internet Explorer.
  3. Идем в Internet Options -> Advanced -> Reset и ставим галочку напротив единственного пункта «Reset personal settings».
  4. Нажимаем Reset и дожидаемся окончания процесса.
  5. Может потребоваться перезагрузка (!). IE скажет об этом всплывающим сообщением на желтом фоне внизу. Перезагружаемся, если требуется.
  6. Запускаем Skype и логинимся (у меня даже пароль не спросил после этого).