1с не запускается через рдп

Обновлено: 06.07.2024

В выпусках Windows 10 Pro можно использовать режим удаленного рабочего стола. Но есть также и режим RemoteApp, как в серверных ОС.

В этом варианте клиенту доставляется не весь Рабочий стол, а только приложение. Возьмем, например, 1С.

Подготовительные действия

1. В дополнительных параметрах системы, на вкладке «Удаленный доступ» выставите разрешение для удаленных подключений .

Опция «Разрешить удаленные подключения к этому компьютеру» Опция «Разрешить удаленные подключения к этому компьютеру»

2. Выберите пользователя , в сеансе которого будет открываться программа 1С. Члены группы «Администраторы» имеют это право по умолчанию.

3. Проверьте настройки вашего брандмауэра — разрешите TCP-порт для входящих подключений (по умолчанию — 3389).

4. В списке служб, оснастка services.msc, должна выполняться TermService — «Службы удаленных рабочих столов».

Как опубликовать приложение 1С на Windows 10

Открыть редактор реестра (regedit) и добавить раздел "1cestart" с соответствующими полями в ветку

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\TSAppAllowList\Applications

Название раздела для публикуемого приложения вы выбираете самостоятельно. В нашем примере — "1cestart".

Текстовые поля REG_SZ: IconPath, Name, Path, RequiredCommandLine, VPath. REG_DWORD: CommandLineSetting, IconIndex, ShowInTSWA.

Делать все это «руками» — достаточно трудоемко, и можно запросто ошибиться. Поэтому ↴

Запустить reg-файл 1cestart со следующим содержимым

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\TSAppAllowList\Applications\1cestart]
"Name"="1cestart"
"Path"="C:\\Program Files\\1cv8\\common\\1cestart.exe"
"VPath"="C:\\Program Files\\1cv8\\common\\1cestart.exe"
"RequiredCommandLine"=""
"CommandLineSetting"=dword:00000001
"IconPath"="C:\\Program Files\\1cv8\\common\\1cestart.exe"
"IconIndex"=dword:00000000
"ShowInTSWA"=dword:00000000

Использовать программуRemoteApp Tool, с помощью которой выполнить публикацию

Меню « File — New RemoteApp (advanced). », и далее выбираете приложение, которое необходимо опубликовать, через обзор в «App path».

Как создать ярлык для подключения RemoteApp

Допустим, мы создаем подключение к удаленному рабочему столу Windows 10 по адресу "192.168.0.200:3389". В ярлыке указываем именно такой адрес.

1. Создать текстовый файл с именем «1cestart.rdp» и содержанием.

allow desktop composition:i:1
allow font smoothing:i:1
alternate full address:s: 192.168.0.200:3389
alternate shell:s:rdpinit.exe
devicestoredirect:s:*
disableremoteappcapscheck:i:1
drivestoredirect:s:*
full address:s: 192.168.0.200:3389
prompt for credentials on client:i:1
promptcredentialonce:i:0
redirectcomports:i:1
redirectdrives:i:1
remoteapplicationmode:i:1
remoteapplicationname:s: 1cestart
remoteapplicationprogram:s:|| 1cestart
span monitors:i:1
use multimon:i:1

2. Использовать утилиту RemoteApp Tool — меню «Create Client Connection. ».

✅ Так вы можете запустить 1С через RemoteApp на ПК Windows 10, но только для одного пользователя. Либо используете консоль, либо сеанс удаленного рабочего стола.

В основе материала использована публикация «Как включить RemoteApp на Windows 10 Professional» портала Инфостарт .

Вас также может заинтересовать:

Если не сохраняется пароль пользователя для RDP подключений .
Сеанс RDP — что влияет на качество подключения к удаленному компьютеру .
Об использовании com-портов и сканера штрихкодов при запуске 1С в терминальном режиме .
Если принтеры не переносятся в терминальную сессию 1С .
Если не подключаются диски в терминальную сессию сервера Windows .

⚡ Подписывайтесь на канал или задавайте вопрос на сайте — постараемся помочь всеми техническими силами. Безопасной и производительной работы в Windows и 1С.

Приходит как то больше года назад владелица бухгалтерской фирмы в офис, а там:

В общем шифровальщик и всё такое .
Были бэкапы, вопрос относительно безболезненно решился. Но, были полностью утеряны две не критичные базы 1С и встал закономерный вопрос что же предпринять, так как всем было понятно, что "отскочили чудом".
А, тут как раз я, совершенно случайно "мимо проходил" .

Системный администратор фирмы (он скорее 1С-ник) начал говорить какие то довольно странные вещи и я, пользуясь определенным доверием со стороны руководства, решил возглавить процесс поиска решения. Доверием же я был не обделен по причине того, что сам был когда то давно там первым сисадмином.
Довольно быстро мы пришли к выводу, что быстрее и проще всего решить проблему "разорвав" доступные пользователю (с его вирусами) и системе 1С файловые пространства реализовав это через запуск 1С как удаленного приложения.

Собственно это предисловие :)

Дальше началось что то для меня совершенно не понятное и плохо объяснимое .
Тут я понял, что мышление специалистов по 1С серьезно отличается от моего :)

Системный администратор категорично заявил, что для решения вопроса нужно:
1. Выделенный сервер
2. Серверная операционная система
.
х-2. Развертывание чуть ли не 5 ролей с их настройкой
х-1. 3 дня работы как минимум
х. Профит!
О_О

В итоге вопрос был решен в течении двух часов так:
- Windows 10 LTSB 1607 на виртуалке с установленным RDP-Wrapper в качестве сервера терминалов с установленной 1С
- вызов с клиентских машин программы 1С скриптом в виде текстового файла с расширением *.rdp

Содержимое файла:
-------------------------------------------
full address:s:192.168.0.хххremoteapplicationmode:i:1disableremoteappcapscheck:i:1alternate shell:s:rdpinit.exeprompt for credentials on client:i:1remoteapplicationname:s:<<<< 1C >>>>remoteapplicationprogram:s:"C:\Program Files (x86)\1cv8\common\1cestart.exe"redirectclipboard:i:1redirectposdevices:i:0------------------------------------------------
Всё чудесным образом заработало и больше вообще ни чего опасного в защищенную зону предприятия с тех пор не попадало. Прошло больше года. Вирусы бухгалтера у себя на компах локально получали и запускали.

Плюсы:
- сейчас вообще всё равно, что там установлено и как работает на компьютерах бухгалтеров, главное, чтоб "Подключение к удаленному рабочему столу" запускалось
- принтер настроен на виртуалке и печать работает стабильно и не зависимо от состояния дел на не особенно новых клиентских машинах сотрудников
- администрирование доступа к базам предельно упрощено для администратора
- стал возможен бэкап не только баз 1С, но и всей виртуальной машины
- 1С-ник утверждает, что 1С сейчас работает гораздо стабильнее и до этого ОНО так хорошо ни когда не работало

Минусы:
- новые бухгалтеры по началу путаются в файловых пространствах и забывают, что диски и папки в 1С к их компьютеру отношения не имеют. Пугаются, Впадают в панику :)

------------------------------
Написать этот опус меня сподвиг аналогичный случай, произошедший недавно в подобной конторе и растерянность специалиста по 1С при решении простой проблемы.
А, тут, собственно, "три кнопки нажать" :)

Всё описано очень кратко. Ни один правообладатель не пострадал.
Детали, если кому интересно, в коментах .

На самом деле это не является ошибкой, это является уведомлением о проблеме безопасности давно не обновлённого сервера.

Microsoft отреагировала на уязвимость и приступила к устранению проблемы, поделив шаги на 3 этапа.

Результат первого этапа – обновление от 13 марта 2018 года, для CredSSP и RDP, которое закрывает дыру в безопасности и добавляет новый пункт в групповые политики.

Результат второго этапа – обновление от 17 апреля 2018 года, которое предупреждает о небезопасном соединении, если у сервера или клиента будет уязвимые CredSSP или RDP.

Результат третьего этапа – как раз обновление от 8 мая 2018 г.

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

Политика должна располагаться по пути:

Computer Configuration -> Administrative Templates -> System -> Credentials Delegation -> Encryption Oracle Remediation

Конфигурация компьютера -> Административные шаблоны -> Система -> Передача учётных данных -> Исправление уязвимости шифрующего оракула

Политика имеет 3 опции:

1. Vulnerable (оставить уязвимость) – клиенты смогут подключаться как раньше, не зависимо от того, пропатчены они или нет. Это уязвимый уровень безопасности.

2. Mitigated (уменьшить риск) – клиенты не смогут подключаться к непропатченым серверам, в свою очередь серверы смогут принимать непропатченных клиентов. Средний уровень безопасности.

3. Force Updated Clients (принудительно принимать обновленные клиенты) – безопасный уровень взаимодействия клиентов – соединение установлено не будет, если один из пары клиент-сервер имеет не пропатченный RDP.

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

Служба располагается по пути:

Start -> Control Panel -> Administrative Tools -> Services

Пуск -> Панель управления -> Администрирование -> Службы

Для Windows Server 2008 R2 SP1 или Windows Server 2012 R2 мы можете установить не все обновления, а только одно, которое устраняет эту уязвимость, сокращая время на решение проблемы подключения к серверу.

Информационная безопасность

1.2K постов 22.7K подписчиков

Правила сообщества

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

1. Если вы добавляете пост, утверждающий об утечке данных или наличии дыр в системе, предоставьте ссылку на источники или технически подкованное расследование. Посты из разряда "Какой-то банк слил данные, потому что мне звонили мошенники" будут выноситься в общую ленту.
2. Все вопросы "Как обезопасить сервер\приложение\устройство" - в лигу "Компьютер это просто".

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

Добавление ссылки разрешено если она не содержит описание коммерческих (платных) продуктов и/или идентификаторов для отслеживания перехода и для доступа не нужен пароль или оплата в т.ч. интернет-ресурсы, каналы (от 3-х тематических видео), блоги, группы, сообщества, СМИ и т.д.

Запрещены политические holy wars.

По решению модератора или администратора сообщества пользователь будет забанен за:

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

2. Публикацию поста/комментария не соответствующего тематике сообщества, в том числе обсуждение администраторов и модераторов сообщества, для этого есть специальное сообщество.

3. За обвинение в киберпреступной деятельности.

4. За нарушение прочих Правил Пикабу.

Пикабу становится источником информации лучшем чем Microsoft Support.

Нужно от имени одмина запустить cmd и выполнить следующее:

REG ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters /v AllowEncryptionOracle /t REG_DWORD /d 2

ябстественно это делается не на сервере, а на клиентской машине

Чувак! Спасибо. Сэкономил кучу времени. Дополню, что в русской локали все не так очевидно

Спасибо ! В 2020 столкнулся с проблемой на вин10 и способ все еще работает.
Что странно - сервера ( проверял больше десяти) все обновлены не более недели назад и новых апдейтов нет.

Капец. Сегодня столкнулся с этой фигней. Предыдущий админ обновления на серваке не включил. Пришлось отдельно качать. Но приятно что я эту инфу увидел на Пикабу. Респект.

это только для Windows Server?

Вылезла проблема в одном из отдела, обнову удалил. Щас попробую ваш вариант.

прям выручил человечище

Что-то я не совсем понял в чем уязвимость? В том что любой человек может по сути дела зайти на любой сервер, у которого включен рдп доступ через интернет? Или в том что пользователи, которые зашли, но не имели определенных прав смогут сделать все что угодно? И если сделать уровень безопасности Mitigated то по сути это не поможет?

Спасибо, добрый человек.

Спасибо Автор, помогло =) Был рад найти ответ на свой вопрос на пикабу ) А то думаю что за фигня. Обновы накатил, теперь уже все пучком ) Вернул все в зад ))

Работает 100% для WinServ2012

gpedit.msc / computer configuration / administrative templates / windows component / remote desktop services / remote desktop session host / security

"require user autentification for remote connection" -> DISABLED

во отлично все, круто, 100500 плюсов

Дай тебе Бог здоровья.

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

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

Спасибо, добрый человек. Утром видел ваш пост, сел поработать сейчас, и бах, эта ошибка)

@Rastov, бро! Спасибо тебе, мы как - то упустили этот патч. Кучу времени нам спас!

Полдня потратил на решение проблемы, и никак, нашел данную статью сделал на своем компе, но не помогло (правда не перезагружал). И в этот момент обновлялся сам сервер, перезагрузил сервер и все заработало как было.

Столкнулся сегодня. Временно решил отключением проверки подлинности на уровне сети.

Проверил после обновлений. Все работает. Больше спасибо. В закладки. +

Обновите систему. На костылях далеко не убежишь. Ботнет уже варежки вяжет на ваших ПК.

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

Shodan.io | Как спастись, куда бежать начинающему разработчику/сис.админу?

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

Занимаюсь веб и не очень разработкой порядка восьми лет, однако руки до VDS и собственных серверов дошли совсем недавно, так как являюсь дуб дубом в вопросе настройки серверов и человеком не особо интересующимся трендами -- пропустил явление "shodan". как оказалось -- очень зря, за что и поплатился в последствии и от чего хочу оберечь новичков.

Кратко о shodan. Это поисковый сервис который рандомным образом генерирует IP адресы и проверяет что по ним расположено, в следствии неправильной настройки сервера некоторые данные могут утечь (shodan не щадит никого) либо к серверу может быть получен несанкционированный доступ. К примеру, есть такой пакет для linux совместимых систем как ProFTPD (FTP сервер, что логично) и в нём есть (был?) эксплоит (CVE-2019-12815) позволяющий выполнять код и доставать "секретную" информацию БЕЗ авторизации. Актуально для версии пакета 1.3.5b.
Патч на гитхаб: https://github.com/lcartey/proftpd-cve-2019-12815
Чем опасен этот эксплоит помимо очевидного "выполнять код"? Да всё очень просто, если у вас к серверу привязан домен и не стоит патч на proftpd, то последний любезно предоставит информацию о нём.

Если вы используете услуги аренды VDS серверов, крайне не рекомендую вообще указывать реальный домен при начале аренды (актуально как минимум для firstvds).

Если вы используете на своём сервере Apache2 -- настоятельно рекомендую озаботиться об установке на него патчей если таковые имеются (а у апача их достаточно, в зависимости от версии), либо же установить nginx и работать с ним.

Также крайне не рекомендую при наличии домена, разрешать доступ к серверу через IP.
Для себя я решил проблему с доступом через добавление в конфигурацию nginx'а следующих строк:

Для своих сайтов я использую Cloudflare который прекрасно справляется с экранированием запросов и инициатор запросов никогда не получит ваш реальный IP адрес.

Если вы используете свои сертификаты но используете и Cloudflare -- стоит изменить этот сертификат на Origin сертификат от Cloudflare. Зачем? Для того чтобы при обращении через IP на 443-й порт (если таковой активен, при наличии сертификата) -- не сообщить злоумышленникам домен. Чем бережнее вы относитесь к секретности IP, тем меньше будет вероятность DDoS атаки, поскольку например Cloudflare -- успешно их отражает (в большинстве случаев).

Не стоит думать что если между IP адресом вашего сервера и доменом была установлена связь, вас никогда не затронет проблема безопасности. У каждого разные причины для тех или иных поступков, будь то просто зависть или попытка устранить конкурента. Будьте бдительней, господа!

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

Ну а я после этого поста готовлюсь огребать минусы от "знатоков". Тем не менее, я сообщил о том о чём знал и теперь моя совесть чиста, надеюсь кому-нибудь да поможет.

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

Ошибка сети удаленного рабочего стола

Отсутствие допустимого канала связи может помешать клиенту подключиться к сеансу удаленного рабочего стола. Диагностировать проблему можно через процесс устранения.

Сначала попробуйте установить сеанс от клиента, который уже смог успешно подключиться. Цель состоит в том, чтобы выяснить, относится ли проблема к конкретному клиенту или сети.

Если вы подозреваете, что виновата сеть, попробуйте сузить сферу действия проблемы, чтобы найти основную причину. При этом вы можете обнаружить, что проблема затрагивает беспроводные соединения, но не проводные. Кроме того, вы можете обнаружить, что проблема уникальна для трафика VPN или конкретной подсети.

Проблемы с брандмауэром

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

Инструменты на основе протокола удаленного рабочего стола (RDP) по умолчанию используют порт 3389. Некоторые публичные сети блокируют трафик RDP. Это особенно верно в отношении сетей Wi-Fi.

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

Вам также может потребоваться настроить несколько брандмауэров. Например, клиент и сервер могут запускать брандмауэр Windows, и между двумя системами, вероятно, будет один или несколько аппаратных брандмауэров.

Проблемы с сертификатом SSL

Сертификаты безопасности также могут вызвать проблемы с подключением к удаленному рабочему столу. Многие продукты VDI используют шифрование Secure Sockets Layer (SSL) для пользователей, которые получают доступ к сеансам VDI за пределами периметра сети. Но SSL-шифрование требует использования сертификатов, что создает две проблемы, которые могут привести к неработоспособности удаленного рабочего стола.

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

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

Клиент также должен иметь возможность проверить сертификат, который использует сервер. Процесс проверки может прерваться, если срок действия сертификата истек или имя в сертификате не совпадает с именем сервера, использующего его.

Проблемы с DNS

Многие проблемы с подключением к удаленному рабочему столу могут быть связаны с проблемами DNS. Если администратор изменил IP-адрес хоста, клиенты не смогут подключиться к хосту, пока не истечет срок действия кэша распознавателя DNS клиента.

Введите следующую команду на клиентском компьютере, чтобы очистить кэш и принудительно разрешить имена DNS: IPConfig / FlushDNS

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

Ошибки аутентификации

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

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

Превышение емкости инфраструктуры

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

Отключенные соединения

Иногда клиент может установить сеанс RDP, но доступная пропускная способность не будет соответствовать требованиям сеанса. В зависимости от используемого клиента RDP эта проблема может проявляться различными способами.

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

Вы можете настроить клиент RDP для использования более низкого разрешения экрана или глубины цвета и отключить визуальные функции, такие как сглаживание шрифтов или фон Windows.

Проблемы CredSSP

Иногда подключение RDP может не работать из-за проблем с протоколом поставщика поддержки безопасности учетных данных. CredSSP предоставляет средство отправки учетных данных пользователя с клиентского компьютера на хост-компьютер, когда используется сеанс RDP.

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

Читайте также: