Ошибка «Процесс сервера не может быть запущен, так как указана неправильная идентификация» при синхронизации 1С

Ошибка «Процесс сервера не может быть запущен, так как указана неправильная идентификация» — типичная проблема при обмене данными между базами 1С через COM-соединение, а также при фоновой синхронизации, когда платформа пытается запустить COM-сервер (V83.COMConnector или объект другой базы) от имени учётной записи, которой не хватает прав. Ошибка приходит из Windows (уровень DCOM), а не из самой конфигурации, поэтому искать её нужно в настройках безопасности операционной системы.

Чаще всего сообщение появляется в журнале регистрации при выполнении плана обмена «Синхронизация данных через универсальный формат» или при обмене «1С:Управление торговлей» ↔ «1С:Бухгалтерия», когда базы расположены на разных компьютерах. Реже — при локальной синхронизации, если служба агента сервера 1С или планировщик заданий работают от имени пользователя без необходимых разрешений DCOM.

Хорошая новость: в подавляющем большинстве случаев проблема решается корректной настройкой идентификации COM-приложения и прав доступа, без переустановки платформы. Ниже разберём, как локализовать источник, что проверить в первую очередь и как безопасно исправить настройки.

Что означает ошибка и откуда она берётся

Синхронизация между базами 1С в файловом или клиент-серверном варианте часто строится на COM-подключении: одна база вызывает другую через объект V83.COMConnector. Когда COM-клиент обращается к серверу, Windows проверяет, от чьего имени должен быть запущен процесс сервера — это и есть «идентификация».

В настройках DCOM-приложения (раздел «Component Services») на вкладке «Удостоверение» может быть указано: интерактивный пользователь, запускающий пользователь, конкретная учётная запись с паролем или системная учётная запись. Если указан конкретный пользователь, а его пароль изменился, учётная запись заблокирована или удалена, Windows возвращает именно эту ошибку — «указана неправильная идентификация».

Второй типовой сценарий — синхронизация запускается регламентным заданием на сервере 1С. Серверный процесс работает от имени учётной записи службы агента сервера (часто USR1CV8), и если у этой записи нет прав DCOM на запуск и активацию компонента, обмен падает с тем же сообщением.

Как локализовать источник проблемы

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

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

Также проверьте журнал событий Windows (Просмотр событий → Журналы Windows → Система) на обоих компьютерах в момент ошибки: события источника DistributedCOM с кодами 10016 и подобными укажут конкретный компонент и учётную запись, которой отказано в доступе.

Проверка учётных данных подключения в 1С

Первое и самое простое действие — открыть настройку синхронизации в 1С и заново ввести параметры подключения к базе-корреспонденту. Перейдите в раздел «Администрирование» → «Синхронизация данных», откройте настройку обмена и проверьте тип подключения: COM-соединение, веб-сервис или обмен через каталог.

Если используется COM-подключение, убедитесь, что путь к базе (или сервер и имя базы) указан корректно, а логин и пароль пользователя базы-корреспондента актуальны. После смены пароля пользователя в базе-корреспонденте старые сохранённые данные становятся источником именно таких ошибок. Введите пароль заново и нажмите «Проверить подключение».

Учтите: пользователь, указанный для подключения, должен существовать в базе-корреспонденте и обладать правами на чтение и запись объектов обмена. Проверка подключения из формы настройки — самый быстрый способ отделить проблему учётных данных 1С от проблемы DCOM на уровне Windows.

Настройка DCOM и удостоверения COM-приложения

Если учётные данные в 1С верны, переходите к оснастке управления компонентами. На компьютере, где находится база-корреспондент (или где должен запускаться COM-сервер), выполните команду dcomcnfg, раскройте «Службы компонентов» → «Компьютеры» → «Мой компьютер» → «Настройка DCOM» и найдите приложение V83.COMConnector (может отображаться как «V83.COMConnector.1»).

Откройте свойства компонента и перейдите на вкладку «Удостоверение». Если выбран вариант «Текущий пользователь» или «Указанный пользователь», а синхронизация выполняется службой без интерактивного входа, переключите на «Системная учётная запись» либо укажите конкретного пользователя с актуальным паролем и правами локального администратора. После смены пароля этой учётной записи пароль здесь нужно обновить вручную — Windows этого не делает автоматически.

На вкладке «Безопасность» откройте «Разрешения на запуск и активацию» → «Настроить» и добавьте учётную запись, от имени которой выполняется синхронизация (например, USR1CV8 или пользователь планировщика), с правами «Локальный запуск», «Удалённый запуск», «Локальная активация» и «Удалённая активация». Аналогично проверьте «Разрешения на доступ».

Проверка результата и контрольные точки

После внесённых изменений выполните синхронизацию вручную и дождитесь завершения. Успешный результат — отсутствие ошибок в форме обмена и появление записей о загруженных и отправленных данных. Затем проверьте журнал регистрации: события обмена должны завершаться без ошибок подключения.

Запустите регламентное задание принудительно (через консоль заданий или обработку управления регламентными заданиями) и убедитесь, что оно отрабатывает под той же учётной записью, что и по расписанию. Только после этого можно считать проблему решённой — ручной запуск из сеанса администратора не гарантирует работу фонового обмена.

Контрольные точки

Как проверить результат

Ручная синхронизация

Норма

Обмен завершается, данные загружены и выгружены

Тревожный признак

Ошибка подключения или идентификации повторяется

Регламентное задание

Норма

Задание выполняется по расписанию без ошибок в журнале регистрации

Тревожный признак

В журнале регистрации аварийное завершение фонового задания

Журнал событий Windows

Норма

Нет новых ошибок DistributedCOM в момент обмена

Тревожный признак

События с отказом в доступе для учётной записи службы

Данные в базе-корреспонденте

Норма

Документы и справочники появились на другой стороне

Тревожный признак

Обмен «прошёл», но данных нет — проблема уже в настройках правил

Типичные ошибки и альтернативные подходы

Распространённая ошибка — исправление только одного звена: меняют пароль в настройках синхронизации, но забывают про удостоверение COM-приложения, или наоборот. Идентификация проверяется на нескольких уровнях, и несоответствие в любом из них возвращает ту же ошибку.

Если настройка DCOM по каким-то причинам невозможна (политики безопасности, разные подсети, отсутствие административного доступа), рассмотрите альтернативные транспорты обмена: синхронизацию через веб-сервисы, обмен через каталог (локальный, FTP или сетевой ресурс) или сервис «1С:Предприятие через Интернет». Эти варианты не используют COM-подключение и полностью снимают проблему идентификации DCOM.

Сравнение вариантов транспорта обмена

COM-подключение

Быстро и прямое соединение, но требует настройки DCOM, совместимых версий платформы и сетевой доступности

Обмен через каталог

Простая настройка без DCOM, подходит для разных сетей; минус — обмен не в реальном времени и зависит от доступности каталога

Веб-сервисы

Работает через HTTP/HTTPS, удобно для удалённых баз; требует публикации базы на веб-сервере

FTP / сетевой ресурс

Подходит при невозможности прямого подключения; нужен контроль прав на каталог и стабильности канала

Часто задаваемые вопросы

Почему ошибка появилась «сама по себе», хотя ничего не меняли?

Чаще всего изменилось то, о чём забыли: истёк или был сменён пароль учётной записи службы, учётная запись заблокирована политикой безопасности, обновление Windows сбросило разрешения DCOM или была переустановлена платформа 1С, и COM-компонент зарегистрировался заново с настройками по умолчанию.

Нужно ли переустанавливать платформу 1С при этой ошибке?

Нет, в большинстве случаев достаточно настройки DCOM и учётных данных. Переустановка платформы оправдана только если COM-компонент повреждён или не зарегистрирован — это проверяется попыткой выполнить подключение через тестовую обработку или PowerShell с созданием объекта V83.COMConnector.

Ошибка возникает только при обмене с удалённым компьютером. Что проверить в первую очередь?

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

Можно ли избежать настройки DCOM вообще?

Да. Переведите синхронизацию на обмен через каталог, FTP или веб-сервисы — эти транспорты не используют COM-подключение. Для обмена между локальной и облачной базами также существуют штатные механизмы синхронизации через Интернет, не требующие DCOM.

Как понять, что проблема именно в DCOM, а не в пароле пользователя 1С?

Проверьте подключение кнопкой «Проверить подключение» в настройках синхронизации. Если ошибка звучит как «неправильная идентификация» на этапе создания COM-объекта — это уровень Windows/DCOM. Если подключение создаётся, но отклоняется вход в базу — это уже учётные данные пользователя информационной базы.

Безопасно ли указывать конкретного пользователя на вкладке «Удостоверение»?

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