Произошла ошибка при сохранении в файл rdp
Обновлено: 07.07.2024
Рассмотрим случай, когда в сеансе Remote Desktop не подключаются локальные диски. Теряется удобство при сохранении файлов на клиентские диски при работе с приложениями 1С на сервере.
Что можно сделать?
Рассмотрим на примере сервера Windows Server 2008 R2.
Важно: новые настройки проверяем при полном завершении терминальных сессий пользователя (выход из сеанса) на сервере 1С.Если не подключаются диски в терминальную сессию сервера Если не подключаются диски в терминальную сессию сервера
Настройки на терминальном сервере 1С
1. Проверьте настройки служб терминалов через « Пуск — Программы — Администрирование — Службы удаленных рабочих столов — Конфигурация сервера узла сеансов удаленных рабочих столов ».
В свойствах конфигурации подключения во вкладке « Параметры подключения » не должен быть отмечен чек-бокс « Диск » в блоке « Отключить следующее ».
2. Для учетной записи пользователя на сервере проверьте настройки профиля через « Локальные пользователи и группы — Пользователи ».
В свойствах профиля во вкладке « Среда » должны быть разрешены устройства клиента.
В частности, активна опция « Подключение дисков клиента при входе ».
3. Проверьте настройки групповой политики.
В разделе « Конфигурация компьютера — Административные шаблоны — Компоненты Windows — Службы удалённых рабочих столов — Узел сеансов удалённых рабочих столов — Перенаправление устройств и ресурсов » политика « Не разрешать перенаправление дисков » должна быть отключена или не задана (по умолчанию).
Прочие рекомендации:
- установите обновления системного ПО через «Центр обновления Windows», если таковые имеются;
- сделайте перезапуск (перезагрузку) терминального сервера 1С — бывает, что помогает обычный reboot.
Настройки на клиенте 1С
Вариант 1-й — Запустите приложение «mstsc.exe» (Подключение к удаленному рабочему столу).
Выберите «Показать параметры», переключитесь на вкладку «Локальные ресурсы — Подробнее» и убедитесь, что в разделе «Диски» отмечены необходимые локальные устройства.
Описание проблемы
Есть сервер с операционной системой Windows Server 2012 R2, сотрудник пытается к нему подключиться, через классическую утилиту "Подключение к удаленному рабочему столу", в момент авторизации, выскакивает окно с ошибкой "Произошла внутренняя ошибка".
В английском варианте ошибка звучит вот так:
После этого у вас разрывается соединение. Когда мы видели моргающий экран по RDP, там хотя бы вы попадали на сервер и могли открыть диспетчер устройств, тут сразу все обрубается на корню. Давайте смотреть, что можно сделать.
Если посмотреть журналы событий на удаленном сервере, куда вы пытаетесь подключиться, то там порядок событий будет такой:
События нужно искать в журнале Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational
Исправляем ошибку "Произошла внутренняя ошибка"
Так как по RDP подключиться не получается, то первым делом нужно проверить отвечает ли порт, по умолчанию это 3389. О том, как проверить порт на удаленном сервере я вам описывал, там все сводилось к выполнению команды Telnet, ознакомьтесь. Если порт отвечает, то делаем следующее.
Нужно удаленно перезапустить службу на этом сервере, чтобы сам сервер не перезагружать, так как в этот момент, он может выполнять важные задачи, можно использовать утилиту "Управление компьютером". Открыть ее можно через команду вызова оснастки, вызываем окно "Выполнить", через одновременное нажатие клавиш WIN и R, в котором пишем:
В открывшейся оснастке, щелкните в самом верху по пункту "Управление компьютером" правым кликом мыши, и выберите пункт "Подключиться к удаленному компьютеру".
Выберите пункт "Другим компьютером" и укажите его DNS имя, или найдите его через кнопку обзор.
Когда вы подключитесь к нужному серверу, перейдите в пункт "Службы и приложения - Службы", в списке сервисов найдите службу удаленных рабочих столов (Remote Desktop Services), и перезапускаем ее. После этого ошибка подключения по RDP "Произошла внутренняя ошибка", у вас должна пропасть.
Так же вы можете использовать оболочку PowerShell запущенную от имени пользователя, у которого есть права на удаленный сервер, где будет перезапускаться служба RDP. Выполните:
Get-Service TermService -ComputerName Имя сервера | Restart-Service –force –verboseДополнительные методы решения
Если вам не помог первый метод, перезапускающий службу удаленных рабочих столов, то можно попробовать выполнить правку реестра. Открываете редактор реестра Windows, если у вас физического доступа к серверу нет или он далеко и вам лень до него идти, то можно попробовать подключиться к реестру удаленного сервера.
Для этого в окне "Редактор реестра" пункт меню "Файл - Подключить сетевой реестр".
В открывшемся окне "Выбор компьютера" указываем его DNS-имя или ip-адрес и нажимаем ок. У вас будет установлено подключение к удаленному реестру сервера, что испытывает проблемы.
Находим ключ CheckMode по пути
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ Session Manager\CProIntegrity\CheckMode Перед любыми правками реестра, обязательно сделайте выгрузку нужной ветки, чтобы можно было восстановить все в оперативном режимеВыставляем ему значение о, чтобы отключить у программы КриптоПРО CSP проверку контрольных сумм. Еще один важный момент, если у вас старая версия КриптоПРО, то это так же может быть источником, проблем, недавний пример, это ошибка "Windows installer service could not be accessed". Для этого удаляем правильно КриптоПРО CSP и ставим последнюю доступную версию.
Еще можно попробовать изменить значение вот такого ключа реестра:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ Session Manager\Memory Management\SessionImageSizeНайдите ключ SessionImageSize и задайте ему значение 0x00000020.
Дополнительные настройки RDP клиента
Например ошибка "An internal error has occurred" у меня встретилась на Windows Server 2022 и там мне помогло в настройках клиента RDP отключение некой опции. Перейдите в дополнительные настройки клиента для удаленного подключения, где н вкладке "Experiens (Взаимодействие)" вам нужно убрать галку с опции "Восстановить подключение при разрыве (Reconnect if the connection is droped)"
На каких-то сайтах предлагалось именно активировать данный пункт.
Удаление кэша подключений
Еще одним методом решения внутренней ошибки подключения по RDP может выступать поврежденный кэш, который хранится на локальном компьютере пользователя. Для его отображения вам необходимо включить отображение скрытых папок и удалить содержимое папки:
Что известно.
Есть локальная сеть. Домен. Но не все пользователи работают на своих компьютерах под доменными учетками. Некоторые работают под локальными.
Есть сервер удаленных рабочих столов Windows Server 2016. Пользователи на него заходят через RDP (всегда под доменными учетками), запускают на нем 1С. Используется в основном 8.3.10.2561 толстый клиент обычное приложение и реже 8.3.12.1440 обычное и управляемое приложение. Одновременных пользователей на сервере несколько десятков.
Время от времени, примерно раз-два в неделю происходит непонятное. Начинается все с того, что кто-то из пользюков звонит и говорит, что не может подключиться к удаленке - черный экран. Проверяю. Запускаю RDP. Когда все в порядке открывается окно удаленного рабочего стола с предложением ввести имя пользователя и пароль. А здесь это окно тоже открывается, но оно просто черное. Наш администратор к нему тоже подключиться не может. В итоге все заканчивается перезагрузкой. При этом те, кто ранее зашел на удаленку, продолжают в ней работать не замечая проблем.
Какие догадки.
Есть подозрение, что виноваты люди, которые пытаются сохранять отчеты из 1С себе на компьютер в формате xls. Делают они это через диски, подключаемые средствами RDP. Эти подозрения не беспочвенны. Дважды было так, что при очередном зависании удаленки, звонил пользователь и жаловался, что повисла 1С (в удаленке) при попытке сохранить отчет в xls на свой компьютер (на локальный рабочий стол).
Что надо.
Пожалуйста, посоветуйте, что можно сделать? Может есть какие-то идеи как локализовать проблему? Может такая проблема известна и надо что-то обновить? И сами замаялись и пользюков замаяли.
Спасибо за любую помощь!
Есть подозрение, что виноваты люди, которые пытаются сохранять отчеты из 1С себе на компьютер в формате xls.Как вариант, отключить проброс дисков не навсегда. Если за период отключения не будет таких проблем, то дело скорее всего в пробросе.
Тогда можно его заменить общей папкой, например.
(6)
Похоже, действительно дело в пробросе дисков с клиента.
Есть новая информация:
Удалось найти клиента, который может вешать 1С в RDP (и видимо затем весь сервер). В данном случае была Windows 10 домашняя, не подключенная к домену. Пользователь зашел в RDP, запустил 1С УТ 10, сформировал счет, нажал "Сохранить копию" выбрать папку на своем "проброшенном" диске С, выбрал формат Excel 97 (xls), нажал сохранить. 1С повисла.
Причем мне со своего компа так и не удалось воспроизвести проблему. Даже на RDP заходил под учеткой "плохого" клиента и в 1С тоже под ним, и делал все то же (только сохранял на себя).
Думаю продолжу исследования по специфике "плохого" клиента. Лишать всех проброса дисков не хорошо.
(7) Без потери удобства вместо проброса можно использовать сетевые диски. Это даже лучше, ведь на сетевых дисках, в отличие от "личных", настроено резервное копирование. (8)Сетевые диски у нас не используются по соображениям безопасности. Был прецедент, когда на клиенте завелся шифровальщик и испоганил все что было доступно на сетевых дисках. (10)
Резервного копирования не было. У нас проблема в том, что копия всего файлового хранилища на текущих мощностях делается 5-6 дней (копия с сервера на сервер).
Есть варианты резервного копирования другими способами? (11) Есть. Даже никакой фантазии не надо.
В тот же самый сервер вставить два диска зеркалом. И не монтировать их как диски с буквами.
Потом настроить встроенную Систему архивации данных Windows Server на копирование в те диски.
Да и даже можно без конкретики: просто копируйте на тот же самый сервер. Шифровальщик всё равно испортит только то, что расшарено. До копий никак не доберётся (если они не расшарены). (12) Но остается вопрос, как предотвратить копирование на зеркало уже зашифрованных файлов
(14) Иметь целый каталог резервных копий. У меня, например, делаются копии каждый день и каждая хранится по паре месяцев.
При этом, у меня не хранится 30 объёмов общей папки благодаря инкрементальному копированию.
На данный момент 57 резервных копий общей папки объёмом в 80Гб, занимают 164Гб.
Кстати говоря, это страхует не только от вирусов, но и от ошибки пользователя.
Изредка бывает такое, что файл удалили неделю назад, а он понадобился.
У нас сейчас включены теневые копии два раза в день для логических дисков. Вы это имеете в виду. Но они создаются на том же диске. Можете поделиться, какое Вы используете ПО для резервного копирования или какой функционал Windows Server? (18) Теневые копии можно настроить и на другой диск.
По поводу ПО для резервного копирования я уже ответил в 12. Встроенная компонента
"Система архивации данных windows server"
Подчеркну, это не то же самое, что теневые копии.
(18) теневые копии это хорошо, но недостаточно.
Как-то нет у меня лично к ним доверия.
Старый добрый копи-паст на пару-тройку иных носителей лучше любой теневой копии в разы.
Причем можно делать это программно. Я вот использую Cobian Backup. Вещь хорошая, еще и шифрует файлы в придачу от всякого вирусного отребья.
(11)А если копия с сервера на сервер так медленно делается, можно расширить канал или увеличить производительность дисков. Здесь сразу не скажешь. Надо разбираться, в чём проблема. (13)
Проблема в том, что диски шпиндельные и миллионы мелких файлов.
(11) боже, да как так то, уважаемый?
У вас столь великий объем данных? Или же скорость обмена между серверами столь плоха?
Я вот просто не понял этого момента с ваших слов.
Есть же 2 священных правила:
1. Копии нужно делать. ВСЕГДА.
2. Если вы думаете что копии можно не делать - смотрите пункт 1.
И если проблема со временем и скоростью обмена между серверами - тогда нужно делать копии непосредственно в физической близости к серверу.
(20)Я Ваше возмущение сисадмину передам, но комментировать никак не буду. Я все же больше по 1С. Появились новые подробности.
Нашелся конкретный компьютер, пользователь компьютера не доменный. Если с этого компьютера пользователь подключается к удаленке (к конкретной WinServ2016, на 2012, 2019 косяк не воспроизводится) под доменной учеткой. Запускает 1С (не важно х32 или х64). Формирует любой таб док. Сохраняет в XLS (XLSX не вешает) на свой комп через проброшеный средствами RDP диск (если локально или на сетевой ресурс - то не вешает).
Вот тогда 1С повисает. Закрыть ее не возможно. Какое-то время
15мин могут заходить на сервак другие пользюки. По прошествии нескольких минут выйти из сеанса уже никто не может - висит синий экран с надписью Выход из системы. Если закрыть сеанс крестиком и зайти снова, то опять увидишь этот синий экран с той же надписью. Причем если сеанс не закрывать, то 1С продолжает нормально работать пока не пытаешься что-то сохранять в файлы. Система дает запустить диспетчер задач. Но и через него 1С не закрыть. Проводник не может отобразить содержимое Этого компьютера - пустое окно.
В логах системы вижу:
Через 5мин после повисания 1С: Превышение времени ожидания (30000 мс) при ожидании ответа транзакции от службы "UmRdpService".
Еще через минуту: Превышение времени ожидания (30000 мс) при ожидании ответа транзакции от службы "AudioEndpointBuilder".
В это же время: Программа 1cv8.exe версии 8.3.10.2561 прекратила взаимодействие с Windows и была закрыта. Чтобы узнать, имеются ли дополнительные сведения о проблеме, проверьте историю проблемы в разделе "Безопасность и обслуживание" в панели управления. Путь приложения: C:\Program Files\1cv8\8.3.10.2561\bin\1cv8.exe
Еще: Работа этого приложения была завершена из-за зависания: dwm.exe. Источник Winsrv.
Клиентская ОС Win10 Домашняя. Со всеми обновлениями. RDP 10.0.17134.112 - с других машин с этой же версией косяк не воспроизводится.
Хочется все же разобраться с причинами. Возможно здесь роковое стечение обстоятельств: Конкретная версия сервера с конкретными дровами, конкретная библиотека 1С для сохранения в XLS, конкретная версия RDP, конкретный клиент (что я под этим понимаю - сам не понимаю :).
Попробуйте посмотреть, какие версии Excel установлены на сервере и у клиента(клиентов-юзеров). Желательно, чтоб были после 2007 года, одинаковые. У меня были косяки из-за разных версий.
Если с форматом xlsx нет проблем, то сделайте неиспользование формата xls.
В качестве архивного ПО удобно использовать Cobian Backup, он делает инкременты и универсален.
Каменск-Уральский - очень странный город заводов, вытянутый на 50 км вдоль дороги, там я впервые ощутил дефицит докторской колбасы.
Пробовал тестово сохранять табличные документы с автовысотой строк - проблему воспроизвести не удалось. Видимо дело не в этом (или не только в этом). Все отчеты и печатные формы перелопатить устраняя автовысоту в любом случае не вариант.
UPD (01.05.2020): В первую очередь попробуйте перезапустить службу удаленных рабочих столов на сервере. Если это не поможет :
Одним из способов решить данную проблему это очистка историю RDP подключений на клиенте в ветке HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Servers
Так же может помочь сброс кеша RDP в каталоге C:\Users\%Username%\AppData\Local\Microsoft\Terminal Server Client\Cache (перед очисткой завершите все запущенные сеансы mstsc.exe).
Для очистки кеша используйте команду:
del "C:\Users\%Username%\AppData\Local\Microsoft\Terminal Server Client\cache"
(не забудьте указать корректный путь)
Решений тут несколько:
- Закрыть доступ к серверу по порту 3389 для неизвестных IP-адресов через firewall
- Сменить порты 3389 на любой другой
Как изменить RDP Порт
- Открываем редактор реестра regedit
- Открываем ветку HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TerminalServer\WinStations\RDP-Tcp
- Правим параметр PortNumber в десятичном фрмате
- Порт RDP по умолчанию 3389
- Перезагружаем сервер
- Если у вас на удаленном сервере установлен КриптоПРО, он может быть источником проблем с rdp подключением. Попробуйте отключить проверку контрольных целостности файлов (проверки контрольных сумм) в КриптоПро через реестр. Перейдите в ветку реестра HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\CProIntegrity и измените значение параметра CheckMode на 0. Перезагрузите сервер.
- Если в журнале событий TerminalServices-RemoteConnectionManager вы встретите событие с EventID 1057 (The RD Session Host Server has failed to create a new self signed certificate to be used for RD Session Host Server authentication on SSL connections), перейдите в каталог C:\ProgramData\Microsoft\Crypto\RSA, переименуйте папку Machinekeys в Machinekeys_bak и перезапустите службу TermService.
- Также нашел информацию, что RDP проблема “Произошла внутренняя ошибка” встречалась в Windows 10 1809, если на удаленном компьютере включена политика Configure H.264/AVC hardware encoding for Remote Desktop connections (находится в секции GPO: Computer Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Remote Session Environment). Для решения этой проблемы достаточно отключить UDP протокол для RDP, создав в ветке реестра HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client параметр fClientDisableUDP со значением 1.
Открыть журнала событий RDP
Читайте также: