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

Не запускается RRAS на Windows Server 2019

При настройке VPN-сервера на Windows Server 2019, после установки ролей Routing and Remote Access и NPS и после завершения первоначальной конфигурации роли, практически всегда возникает ошибка при старте службы RRAS. Ошибка выглядит как:

The Routing and Remote Access service terminated with the following service-specific error: 
The callback function must be invoked inline.

И в общем случае вообще ни о чем нам не говорит. При этом, если не устанавливать NPS — всё работает отлично. После долгих изысканий выяснилось, что ошибка возникает только в том случае, если сначала стартует NPS, а после него RRAS. При этом, RRAS в любом случае запускает NPS как зависимость. Очевидное решение — перевести службу NPS из автоматического старта в ручной. После этого проблема больше не воспроизводится.

Внезапная перезагрузка Ryzen 5000 при слабых нагрузках. Решение.

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

Я не хотел прибегать к ручному разгону, как к способу решения этой проблемы (помогает всем), но и постоянные перезагрузки с последующим появлением ошибки WHEA Logger ID 18 — Cache Hierarchy Error (или аналогичных) тоже не давали насладиться спокойной работой на мощном железе. Естественно, я обновлял BIOS, драйвера, пытался включать/отключать различные параметры в настройках BIOS, как и рекомендуют на большом количестве форумов… Не помогало ничего.

Но решить мою проблему помогла случайность. Во время очередных тестов я выставил профиль питания в Windows — Высокая производительность (High performance). Сразу внимания не обратил, но перезагрузки ушли. Затем, через некоторое время, я вернул «Сбалансированный» (Balanced performance) режим и компьютер опять начал перезагружаться. И снова это происходило либо при слабых нагрузках, либо вообще в простое. Возврат профиля «Высокая производительность» снова решил проблему.

Насколько я понял, внезапные перезагрузки возникали из-за попыток ОС Windows управлять состоянием процессора (его частотой или состоянием ядер) при простое. В профиле «Высокая производительность» минимальное состояние процессора равно 100%, т.е. частота не будет снижаться меньше базовой (3.7 ГГц для Ryzen 5900X).

Таким образом, если вы страдаете от внезапных перезагрузок на новом процессоре из серии Ryzen 5000, но ваше остальное железо точно рабочее, а БП способен вытянуть всю систему и стабильно работает под нагрузками — попробуйте поставить «Высокая производительность» в параметрах питания ОС Windows и скорее всего перезагрузки уйдут.

Outlook оставляет копии писем во входящих при перемещении правилами

После миграции с Exchange 2010 на Exchange 2016 всплыл один неприятный глюк: письма, которые автоматически сортируются правилами в аутлуке, начали оставаться в инбоксе. Более подробный анализ показал, что на самом деле они копируются в те директории, в которые они должны перемещаться по правилам.

Стоит заметить, что аутлук 2010 был настроен на хранение всей почты в локальном файле данных, а не на сервере. То есть вся почта хранилась в локальном PST-файле и автоматически удалялась с сервера.

Во всех правилах, которые перемещали письма по директориям, было установлено также действие «Stop processing more rules» (эта рекомендация также встречается при исправлении такой проблемы). Но это не помогало — часть писем исправно сыпались как в инбокс, так и в свою директорию.

После подробного анализа всех писем, которые попадали не по адресу и правил, их сортирующих, была замечена одна маленькая деталь: корректно отрабатывали те правила, в которых было добавлено условие «on this computer only». В итоге, ко всем правилам, которые отрабатывали некорректно, было применено дополнительное условие «on this computer only» и проблема исчезла.

Зависает подключение к удаленному рабочему столу (RDP) при подключении через VPN

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

При использовании RDP поверх VPN периодически могут возникать странные «зависания» удаленного рабочего стола, с последующими дисконнектами или без них или просто значительные подтормаживания интерфейса. Конечно, сначала необходимо исключить проблемы на сетевом уровне (потери пакетов, низкая скорость, высокие задержки и т.д.), но если они уже исключены, а проблемы повторяются — с большой долей вероятности ваш клиент работает по протоколу UDP. Этот режим работы стал режимом по умолчанию начиная с версии RDP 8.0. Сам по себе он призван ускорить работу с RDP, но в связке с VPN-подключением, когда пакеты начинают фрагментироваться перед отправкой в туннель и собираться заново на другом конце — могут возникать проблемы с одновременной доставкой всех «частей» пакета и невозможностью его сборки и, как следствие — задержки и зависания интерфейса.

Отключить работу через UDP можно двумя способами:

  1. Правка реестра. В ветке HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client необходимо создать параметр fClientDisableUDP и установить значение 1.
  2. Групповые политики. Необходимо перейти в Computer Configuration -> Administration Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Connection Client и установить настройку «Turn Off UDP On Client» в Enabled.

После этого зависания должны прекратиться.

Миграция 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 (при наличии).