Ошибка при подключении к существующему сеансу |
Я |
27.09.12 — 11:01
всегда работал нормально с серваком. а тут вдруг выдает:
http://s53.radikal.ru/i142/1209/6e/381ceadf97b3.jpg
и следом:
http://s16.radikal.ru/i191/1209/56/b358d092fbae.jpg
и следом рдп закрывается.
что это значит? мой сеанс сейчас запущен и подо мной на серваке открыт конфигуратор, а я не могу на серв зайти
1 — 27.09.12 — 11:03
(0) Админы права порезали?
2 — 27.09.12 — 11:04
(1) тогда бы сеанс завершился, не?
3 — 27.09.12 — 11:08
(2) Может, через какое-то время и завершится. Хотя и не факт. А вот новые соединения установить уже не даст.
4 — 04.10.12 — 12:56
ап. зашел через тим на сервер, в настройках локальной политики указал группу и пользователей в «Разрешать вход в систему через службу терминалов»
но все равно не рабоатет
5 — 04.10.12 — 13:01
6 — 04.10.12 — 13:09
Так или иначе, существует несколько способов предоставить пользователям права входа на сервер терминалов:
1.
«Панель управления»->»Администрирование»->»Настройка служб терминалов» (или «Пуск»->»выполнить»->tscc.msc)
далее в появившемся окошке «подключения»->»RDP-Tcp»->»Свойства»
в окне свойств RDP-Tcp вкладка «разрешения»
Здесь надо добавить группу (желательно доменную) пользователей которые будут иметь право подключаться к серверу по rdp
пользователи добавленные здесь с правами «доступ пользователя», будут иметь обычные права пользователя на данном сервере их не нужно добавлять в локальную группу пользователей или производить вообще какие-либо дополнительные действия
желательно использовать доменные группы, а не локальные или встроенные.
(см. 1.jpg)
2.
«Мой компьютер»->»управление» (или «Пуск»->»выполнить»->compmgmt.msc)
далее «служебные программы»->»локальные пользователи и группы»->»группы»
выбрать «пользователи удаленного рабочего стола» и добавить в данную группу пользователей или группу пользователей, которым будет разрешен доступ по rdp
по умолчанию «пользователи удаленного рабочего стола» имеют доступ пользователя, так что дополнительных действий производить больше не надо
Способ подходит для использования в рабочих группах, в случае наличия домена, следует использовать способ 1.
(см. 2.jpg)
—-
Следует избегать использование учетных записей пользователей, а использовать для добавления группу, в не зависимости от того, будете вы использовать локальные или доменные записи, добавлять их в группу пользователей удаленного рабочего стола или добавлять группу в настройках служб терминалов.
—-
Если после проделывания вышеописанного, вы по прежнему видете сообщение: «Чтобы выполнить вход на этот удаленный компьютер, нужно иметь разрешение на вход в систему через службу терминалов», то необходимо проверить, не запрещен ли пользователю вход на серверы терминалов в принципе (если есть АД):
Для этого на контроллере домена, либо с любого другова места, где установлены утилиты администрирования, запустите оснастку «пользователи и компьютеры»
«Панель управления»->»Администрирование»->»Active Directory — пользователи и компьютеры» (или «Пуск»->»выполнить»->dsa.msc)
Здесь найдите вашего пользователя и в свойствах на вкладке «Профиль служб терминалов» проверьте отсутствие «Запретить этому пользователю вход на серверы терминалов» (в самом низу над кнопкой «Ок» есть чекбокс)
еще запрет устанавливается в локальных политиках безопасности (возможно распространение данного параметра через ГП)
В не зависимости от способа распространения необходимо убедится в отсутствии запрета
на локальном компьютере:
«Панель управления»->»Администрирование»->»Локальная политика безопасности» (или «Пуск»->»выполнить»->secpol.msc)
здесь «локальные политики»->»назначение прав пользователя»
параметр «запретить вход в систему через службу терминалов»
или
через «редактор объектов групповой политики» (gpedit.msc)
«Конфигурация компьютера»->»Конфигурация Windows»->»параметры безопасности»->»локальные политики»->»назначение прав пользователя»
параметр «запретить вход в систему через службу терминалов»
если явный запрет распространяется через ГП, то
на контроллере домена, либо с любого другова места, где установлены утилиты администрирования
«Панель управления»->»Администрирование»->»Group Policy Management» (или «Пуск»->»выполнить»->gpmc.msc)
«Конфигурация компьютера»->»Конфигурация Windows»->»параметры безопасности»->»локальные политики»->»назначение прав пользователя»
параметр «запретить вход в систему через службу терминалов»
Если явного запрета не обнаружено, а сообщение «Чтобы выполнить вход на этот удаленный компьютер, нужно иметь разрешение на вход в систему через службу терминалов» все еще появляется, то внимательно проделайте все еще раз, чтобы найти то что было упущено, так как описанные 2 варианта полностью работоспособны без дополнительных действий.
все испробовал((
7 — 04.10.12 — 13:10
А через диспетчер служб терминалов нельзя переключиться между сеансами разве?
8 — 04.10.12 — 13:12
(7) сеанса уже нет. диспетчер служб терминалов показывает только один сеанс администратора, в котором я сейчас сижу через тим
9 — 04.10.12 — 13:24
ап
hatsher
10 — 04.10.12 — 13:26
сервер — контроллер домена
-
Question
-
guys i have this error come up if i try to connect via the console to my file/print server after sevral times it will let me in but RDP has stopped working and i have users getting errors when trying to copy files to the server saying there is not enough disk space when there is.
the only blogs i can find about the error message are from 2005 and about a update in service pack 1
All replies
-
I am not able to understand your problem. Can you please explain it in more details? What are you trying to do and what exact error message you are getting?
Thanks!
-
I got the same error when I connect to the server console using ‘MSTSC /CONSOLE’.
«error connecting to existing session for (id 0). the operation completed successfully»
-
I have the same issue on a Windows 2003 Server box. Has anyone was able to solve this?
-
I had the exact same problem.
Fortunately I just solved it. Unfortunately I’m not sure how.anyway it was one of the following (It was late and I made two changes but only one reboot..):
Alternative 1:
1. Start Registry Editor.
2. Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINESystemCurrentControlSetServicesTermServiceParameters
3. Under this registry subkey, delete the following value: • CertificateAlternative 2:
Set MaxIcmpHostRoutes Registry key on Windows 2003 SP1 server.
The following registry change will negate the intention of the fix, as
it count will roll over when it reaches the max value, and will never
hit the max count.KEY_LOCAL_MAXHINESYSTEMCurrentControlSetServicesTcpipParameters
Value Type: REG_DWORD
Set MaxIcmpHostRoutes to 0x7FFFFFFFI made them both and now it works..
На тестовый терминальный сервер всегда подключался через mstsc в свой сеанс, но со вчерашнего дня, при входе выдается такое сообщение:
«Ошибка при подключении к существующему сеансу user.adm (Id 1)
Операция успешно завершена
Будет создан новый сеанс»
и я вхожу только уже в новую сессию. В диспетчере терминалов моих сессий уже три.
В журналах ничего (только по SharePoint-у), в настройках терминальных подключений ничего не менялось, до появления ошибки.
Всё бы ничего, только мне очень нужно войти в свою сессию, что висит, у меня там запущена vmware машина, с важными данными, не могу сделать «Take ownership»…
Подключиться через tsadmin нет возможности, т.к. в политике терминальных разрешений требуется подтверждение от пользователя.
Подскажите в чем проблема?
Обновлено 03.06.2021
Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов в рунете по системному администрированию Pyatilistnik.org. В прошлый раз мы с вами рассмотрели вопрос, как устраняется ошибка с кодом 28 при подключении оборудования в Windows. Идем далее и сегодня я хочу вам показать новую ошибку с которой я столкнулся на RDS ферме буквально на днях, звучит она так «Не удается повторно подключиться к удаленному сеансу» или в английском варианте «Failed to reconnect to your remote session».
Описание ситуации
У меня есть RDS ферма на базе Windows Server 2019, построенная на виртуальных машинах ESXI. Я начал производить базовое обслуживание серверов, обновление VMware Tools, обновление Hardware Version и конечно же сами пакеты обновления Windows. После включения виртуальной машины и попытке подключиться к ней, чтобы проверить все ли корректно работает я получаю ошибку:
Не удается повторно подключиться к удаленному сеансу (Failed to reconnect to your remote session)
После этого если нажать кнопку «Ok» вас просто выкидывает из данного сеанса и при повторной попытке вы будите наблюдать долгую попытку прорваться.
Решение ошибки «Не удается повторно подключиться к удаленному сеансу»
Начав свое исследование я попытался подключиться через «Console» в интерфейсе vCenter, но там было два пути развития:
- У меня вообще не нажималось сочетание клавиш CTRL+ALT+DELETE, просто не реагировала
- Второе, это после ввода логина и пароля я получал вот такое окно, которое не пропадало, на тот момент я ожидал в среднем 2-4 минуты
Далее я попытался подключиться через Windows Admin Center к данному серверу и посмотреть логи Windows, там было несколько предупреждений и пара ошибок с ID 10016.
ID 307: Automatic registration failed. Failed to lookup the registration service information from Active Directory. Exit code: Unknown HResult Error code: 0x801c001d.
SensorLogonTask was unable to correlate result with a logon event.
Данные ошибки, как оказалось не мешали входу, и тут я начал копать дальше. Меня привлекло предупреждение в самом vCenter, что данная виртуальная машина стала потреблять много CPU. Так как попасть на нее не удавалось, я решил удаленно посмотреть все процессы в системе и определить, какой именно из них выедал ресурсы.
Как удаленно посмотреть процессы на сервере
В результате я увидел, что антивирус Касперского (Kaspersky Anti-Virus worker process) выедал весь процессор.
Пробуем дождаться, когда антивирус, что-то до сканирует, у меня это заняло минут 10, после чего я спокойно подключился по удаленному рабочему столу. Так же если у вас Касперский управляется через сервер, то выключите его на время. Если и через 10 минут не получается войти, то я советую вам произвести принудительную перезагрузку (hard reset), возможно у вас какие-то обновления еще не до установились. Надеюсь, что вы так же найдете свою причину данной ошибки, не забывайте поделиться в комментариях своим решением. С вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org.
Довольно часто встречаемая ошибка, имеющая, тем не менее, самые различные причины и методы решения, является ошибка 1С: Существуют активные сеансы с базой…. Не совпадает версия временного файла. Данная ошибка не дает зайти в базу как в режиме Конфигуратор, так и в режиме Предприятие.
Имеется два компьютера, соединенных по сети. На одном из них имеется база 1С, доступная и второму компьютеру. Первый компьютер подключается к базе с помощью платформы 1С версии 8.3.8.2088. Если в это время попробовать подключиться к базе со второго компьютера с помощью платформы 1С версии, отличной от 8.3.8.2088, то мы получим ошибку 1С Существуют активные сеансы работы с данной базой. Такой случай – очевидная причина ошибки.
Однако, помимо этой ситуации, к удивлению, есть множество других причин, способных вызвать аналогичную ошибку. Порой, её можно обнаружить даже при отсутствии сетевого подключения к базе (когда с базой работает один компьютер). Именно поэтому мы создали список действий, выполнение которых позволит Вам преодолеть данную ошибку. Выполнять его полностью необязательно, после каждого пункта рекомендуем проверить наличие ошибки.
Внимание: перед проведением мер рекомендуется завершить все сеансы 1С, а также перезагрузить основной компьютер для гарантированного отключения всех процессов 1С.
Сэкономьте своё время и обратитесь за помощью к нашим специалистам:
Разные версии платформ на компьютерах
Главной причиной этой ошибки считается различие версий платформ на компьютерах. С помощью картинки-инструкции ниже проверьте, на всех ли компьютера установлена общая для всех версия платформы.
Сделать это нужно в следующем порядке: открыть базу на основном компьютере (на рисунке ПК №1), нажмите в программе 1С значок с буквой i, находящийся в правом верхнем углу. У вас откроется информационное окно, где Вы сможете узнать номер релиза платформы 1С. На других компьютерах открыть папку, в которую установлена 1С (по умолчанию C:Program Files (x86)1cv8). В папке хранятся все установленные релизы 1С. Сверьте, имеется ли релиз с таким же номером, как у основного компьютера. Если он отсутствует, вам необходимо установить его на этот компьютер. Сверить версии платформ нужно на всех компьютерах, работающих в 1С.
Разные релизы в параметрах запуска 1С Предприятие
Если вы убедились, что на всех компьютерах присутствует версия платформы, которая запускается на основном компьютере (см. п. 1), но ошибка все равно появляется, возможно, что в параметрах запуска 1С на других компьютерах установлен релиз платформы, отличный от того, который запускается на втором компьютере. Грубо говоря, факт наличия нужного релиза на компьютере не гарантирует, что именно он используется при открытии базы. Проверить это можно двумя способами:
Если вы убедились, что на всех компьютерах присутствует версия платформы, которая запускается на основном компьютере (см. п. 1), но ошибка все равно появляется, возможно, что в параметрах запуска 1С на других компьютерах установлен релиз платформы, отличный от того, который запускается на втором компьютере. Грубо говоря, факт наличия нужного релиза на компьютере не гарантирует, что именно он используется при открытии базы. Проверить это можно двумя способами:
1. Открывать базу на разных компьютерах по очереди. После открытия базы нажимать на i в правом верхнем углу и смотреть номер релиза, как показано в правой части картинки п. 1.
2. Проверить настройки 1С Предприятие. Для этого нажмите на ярлык 1С: Предприятие, выберите базу и нажмите “Изменить”. В появившимся окне нажмите “Далее”, и попадете на окно, показанное на рисунке ниже. Проверьте, что записано в поле “Версия 1С: Предприятие”. Если оно не заполнено, то при запуске будет использоваться самая актуальная имеющаяся на компьютере версия 1С. Для подстраховки рекомендуем прописать там версию платформы, необходимую для запуска.
Например, на основном компьютере база запускается с релизом платформы № 8.3.2. На втором компьютере имеются релизы № 8.3.1, № 8.3.2 и № 8.3.3. Если поле “Версия 1С: Предприятие” оставить незаполненным, то запускаться автоматически будет 8.3.3. Именно поэтому рекомендуем заполнить поле вручную, записав туда нужный релиз платформы (8.3.2 в примере). Помните, что перед этим нужно убедиться, что нужный релиз установлен на компьютере (см. п. 1).
Очистка кэша базы
Очистите кэш у базы и всех пользователей.
Кэш базы:
Для очистки кэша базы откройте папку с базой (её путь можно узнать, выбрав базу 1С в списке баз; путь будет написан в нижней части окна) и удалите в ней все файлы, кроме 1Cv8.1CD.
Кэш пользователя (выполняется для каждого компьютера):
Откройте 1С со списком баз и нажмите “Настройка” (как показано на рисунке ниже). В появишвемся окне вы увидете путь к папке, где хранится различная информация по 1С. Перейдите в папку по этому пути, и теперь поднимитесь на уровень выше, в папку 1cv8 (из которой вы перешли в tmplts). Здесь хранится кэш пользователя. Удалите все папки с названием типа “5ce8424a-158c-47a1-96dc-27f28b1a8d7a”, то есть содержащие хаотичные символьные сочетания. Должны остаться папки ExtCompT и tmplts, а также несколько файлов. Кэш пользователя нужно очищать на каждом используемом компьютере.
Антивирус Касперского
Нередко антивирус Касперского (в частности, 10 версия) является причиной данной ошибки. Если Вы испробовали все варианты выше, и вам не удалось одолеть ошибку, попробуйте полностью удалить антивирус с компьютера, на котором появляется ошибка в 1С.
Сэкономьте своё время и обратитесь за помощью к нашим специалистам: