Ошибка идентификатора клиента в 1С при работе через RDP: причины и решения

Многие пользователи 1С, работающие через терминальный сервер (RDP), недавно начали сталкиваться с сообщением: «Для текущего пользователя "Имя_сотрудника1" не совпадает идентификатор клиента на текущем рабочем месте "Имя_сотрудника2". Возможно менялись характеристики сервера RDP. Выберите дальнейшее действие или обратитесь к администратору». В этой статье разберем, почему появляется это сообщение, как работает механизм идентификации рабочих мест в 1С и какие действия помогут решить проблему.

Причины возникновения ошибки

Ключевая причина — изменение идентификатора клиента, который платформа 1С генерирует и сохраняет в файле %userprofile%\AppData\Local\1C\1cv8\1cv8u.pfl. В большинстве типовых конфигураций это значение является основой для поиска записи в справочнике «Рабочие места». При работе через RDP сервер Windows может каждый раз генерировать новый ID, воспринимая каждое подключение как новое устройство. Эта ситуация особенно характерна для сред, где не настроено сохранение профилей пользователей, а также при использовании веб-клиента (там ID может различаться даже для разных браузеров на одной машине). Кроме того, идентификатор может измениться после восстановления или «лечения» файловой базы утилитой chdbfl.exe или при сбоях в работе терминального сервера, когда профиль пользователя не сохраняется корректно

Механизм «Рабочих мест» в 1С

1С использует справочник «Рабочие места» для надежной идентификации клиентских устройств. Это критически важно при работе с подключаемым оборудованием (кассы, сканеры штрихкодов, принтеры этикеток) и для разграничения доступа. Когда пользователь впервые запускает 1С на новом устройстве, платформа считывает СистемнаяИнформация.ИдентификаторКлиента и автоматически добавляет запись в этот справочник.

В общем виде бизнес-логика выглядит следующим образом: СистемнаяИнформация.ИдентификаторКлиента → поиск по справочнику «Рабочие места» → если запись найдена, используются её настройки → если нет, предлагается создать новое рабочее место. При смене ID старая запись становится недоступной, что и вызывает появление сообщения об ошибке.

Способы исправления ошибки

1. Исправление на стороне RDP-сервера (рекомендованный способ)

Самый надёжный метод — предотвратить изменение идентификатора клиента на уровне терминального сервера. Предлагаются следующие варианты:

• Разные учётные записи Windows: создайте для каждого пользователя, работающего с RDP, отдельный логин в системе. Это гарантирует, что профили и идентификаторы не будут пересекаться.
• Удаление проблемного профиля: удалите пользователя Windows через оснастку lusrmgr.msc, а затем — его папку в каталоге C:\Users. После этого создайте пользователя заново. В некоторых случаях это останавливает постоянную генерацию новых идентификаторов. Обратите внимание: если просто удалить папку профиля, идентификаторы могут продолжать меняться.
• Настройка проброса имени компьютера: в настройках RDP-клиента на стороне пользователя можно включить передачу имени локального ПК, а в коде 1C — привязаться к ИмяКомпьютера(). При корректной настройке в RDP-сессии это имя может соответствовать имени клиентской машины.

Если сервер управляется силами провайдера или внутреннего администратора, рекомендуется делегировать эти изменения специалистам по RDP-инфраструктуре.

2. Доработка конфигурации 1С (программный путь)

Если изменение настроек RDP невозможно или нежелательно, можно адаптировать логику определения рабочего места в самой 1С:

• Привязка к имени компьютера: Для этого в модуле МенеджерОборудованияВызовСервера следует переопределить функцию получения текущего рабочего места, заменив поиск по идентификатору клиента на поиск по ИмяКомпьютера(). Это требует создания нескольких процедур для сохранения имени ПК в параметры сеанса и последующего запроса к справочнику.
• Комбинация параметров: в сценариях RDP оптимально использовать связку ИмяКомпьютера() + имя пользователя ОС или номер сессии (если доступна информация через API).
• Ручная корректировка справочника: если количество пользователей невелико, можно вручную обновить записи в справочнике «Рабочие места», подставив актуальные идентификаторы клиента, извлечённые из файла 1cv8u.pfl каждого пользователя.

Последний вариант даёт временный эффект, но постоянное изменение ID потребует автоматизации.

Когда и в каких версиях программы появляется данная ситуация?

Исторический контекст

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

Однако именно повсеместное проявление ошибки в виде отдельного модального сообщения с тремя кнопками-действиями («Обновить идентификатор», «Создать новое рабочее место», «Продолжить работу») относится к более позднему периоду.

Версии конфигураций

Данное сообщение гарантированно воспроизводится в следующих актуальных релизах "Управления торговлей" и других конфигурациях на базе БСП, где реализована полноценная подсистема «Рабочие места» в составе библиотеки подключаемого оборудования:

• Управление торговлей, редакция 11 (УТ 11) — большинство релизов и актуальных обновлений вплоть до 11.5.26.x включительно. Механизм проверки идентификатора клиента уже долгое время является штатным, однако с обновлениями подсистемы БСП он становился всё строже. В версиях от УТ 11.5.22.134 и выше проявление ошибки особенно заметно из-за доработок в формах ввода подключаемого оборудования. В версиях УТ 11 от 11.4.x проблема могла проявляться не в виде явного сообщения, а в виде сброса настроек оборудования.
• Бухгалтерия предприятия 3.0 (БП 3.0) — начиная с релизов, где появилась подсистема "Рабочие места" (например, для подключения корпоративных карт и устройств чтения смарт-карт), может воспроизводиться аналогичная ошибка при запуске через RDP.
• 1С:ERP Управление предприятием 2 (ERP 2) — проблема также характерна для редакции ERP 2.4 и более поздних версий.
• 1С:Розница 2.3 (Розница 2.3) — при работе кассовых терминалов через RDP.

Условия появления

Очевидно, что для появления ошибки необходима совместная работа трех факторов: работа через RDP, использование конфигурации на современной БСП (версия БСП 3.0 и выше) и одно рабочее место windows для нескольких пользователей или неправильно сконфигурированные профили пользователей. С 2024 года в связи с переходом бизнеса на гибридные и облачные рабочие места, количество жалоб на данную ошибку значительно возросло, особенно на терминальных серверах Windows Server 2019 / 2022.

Насколько критична эта проблема?

Практические рекомендации для администраторов

Исходя из анализа проблемы, системным администраторам и специалистам 1С стоит придерживаться следующего алгоритма:

1. Диагностика среды: выяснить, генерируется ли каждый раз новый ID (можно отследить изменения через системный мониторинг или проверкой файла 1cv8u.pfl до и после перезапуска).
2. Приоритет — изменение настроек RDP: стабильные профили Windows — единственное гарантированное решение на уровне платформы.
3. Временное ручное исправление: если проблема уже возникла и требует немедленного решения, используйте кнопку «Обновить идентификатор у текущего рабочего места» или «Создать новое рабочее место». Не рекомендуется выбирать «Продолжить работу», так как это может привести к конфликтам настроек рабочего места (например, к путанице с подключаемым оборудованием).
4. Программная адаптация: если перечисленные административные меры невозможны, закажите доработку конфигурации по привязке рабочих мест к имени компьютера (или комбинации параметров).

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