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

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

Group Policy, Networks, registry, Windows,

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

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

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

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

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

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

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

Открытие документов Excel в разных окнах (в разных процессах)

registry, Windows

Иногда приходится решать задачи, которые админскими не назовешь, но пользователи сами решить не могут. Один из таких примеров — открытие документов Excel в разных процессах. По умолчанию, Excel 2010 не позволяет расположить рядом на одном экране 2 открытых документа. Также, невозможно разместить 2 документа одновременно на двух мониторах. Исключение составляют те случаи, когда первый документ мы открыли «как обычно» двойным кликом по нему, затем запустили еще одну копию Excel и открыли второй документ в нем. А между тем, эта фича довольно полезна: если у вас «упадет» excel из-за кривых VBA-скриптов — закроются не все документы, а только упавший. Да и  легче сравнивать и переносить данные из одного документа в другой.

К счастью, решение этой проблемы, по крайней мере для Office 2010 существует. Необходимо всего-то изменить парочку записей в реестре:

1. Открываем regedit (Win+R->regedit->Enter);

2. Переходим в HKEY_CLASSES_ROOT\Excel.Sheet.12\shell\Open\command;

3. Кликаем дважды на ключе (Default) справа и изменяем строку на такую (т.е. в конце строки меняем /dde на /e «%1»:

"C:\Program Files\Microsoft Office\Office14\EXCEL.EXE" /e "%1"

4. Переименовываем ключ command в command2;

5. Переименовываем раздел ddexec в ddexec2.

6. Пользуемся :)

Excel 2010 separate processes

Если захочется открывать так не только xlsx файлы, но и xls — достаточно проделать эти же операции с веткой HKEY_CLASSES_ROOT\Excel.Sheet.8\shell\Open\command

NEC VMWar VMware IDE CDR10 ATA Device или нерабочий CD-ROM в виртуальной машине

registry, vmware, ,

Возникла у меня как-то необходимость сконвертировать виртуальную машину с Windows 7 из формата VMWare Workstation в VMWare Infrastructure. После конвертации, естественно, очень желательно проапдейтить VMWare Tools. Вот с этим-то, внезапно, и возниклки проблемы. Дело в том, что виртуальный CD-ROM (NEC VMWar VMware IDE CDR10 ATA Device), на который монтируется образ с VMWare Tools по команде Install/Upgrade VMWare Tools, отказался работать и стартовать в системе. Удаление/добавление текущего привода, простое добавление еще одного CD-ROM никакого эффекта не возымели. На всех приводах в диспетчере устройств горел желтый восклицательный знак, а в свойствах светилась ошибка:

Windows cannot start this hardware device because its configuration information (in the registry) is incomplete or damaged. (Code 19)

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

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E965-E325-11CE-BFC1-08002BE10318}

и удалить оттуда ключ с именем UpperFilters или LowerFilters (в зависимости от того, что там есть). После этого простое «обновление драйвера» для устройства моментально решает проблему и CD-ROM снова работает!

Конечно, можно было бы просто закинуть VMWare Tools в гостевую систему и обновить их без привода. Но это не спортивно — проблему необходимо решать, а не обходить ;)