Почему Excel запускается под чужой учетной записью при выполнении регламентного задания 1С и как это исправить

Системный администратор 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

При работе с сервером 1С:Предприятие в клиент-серверном варианте разработчики часто сталкиваются с необходимостью автоматической генерации отчетов. Традиционный сценарий выглядит следующим образом: регламентное задание на сервере запускается по расписанию, формирует табличный документ, открывает через COM-соединение Microsoft Excel, производит форматирование или конвертацию и сохраняет итоговый файл (например, в формате PDF). Однако на практике эта схема таит в себе множество подводных камней, связанных с безопасностью операционной системы Windows и распределенной моделью COM (DCOM).

В этой статье мы подробно разберем крайне специфическую, но распространенную проблему: почему процесс excel.exe, вызванный регламентным заданием из-под служебной учетной записи 1С (например, User1Cv82), внезапно начинает запускаться в сессии текущего администратора, зашедшего на сервер по RDP, и под его личной учетной записью. Мы выясним причины такого поведения системы, проанализируем влияние перехода на 64-битную архитектуру и рассмотрим пошаговую инструкцию по устранению данной проблемы.

Анализ ситуации: как фоновое задание проникает в пользовательскую сессию

Давайте восстановим хронологию событий и проанализируем поведение системы. Серверная служба 1С запущена от имени специального ограниченного пользователя User1Cv82. Регламентное задание выполняется на сервере в фоновом режиме. В этот момент администратор подключается к серверу под своей личной учетной записью и видит, как на его экране буквально «из ниоткуда» открывается окно Microsoft Excel, выполняет операции и закрывается. Диспетчер задач при этом подтверждает, что процесс excel.exe запущен именно под учетной записью администратора, а не службы 1С.

Как такое возможно, ведь операционная система Windows строго разграничивает права и сессии пользователей?

Все дело в механизме работы DCOM (Distributed Component Object Model). Когда в коде 1С выполняется следующая конструкция:

Excel = Новый COMОбъект("Excel.Application");

платформа 1С не запускает исполняемый файл напрямую. Вместо этого она обращается к подсистеме Windows DCOM с запросом: «Мне нужен объект с программным идентификатором Excel.Application». Подсистема DCOM обращается к своим внутренним реестрам, находит соответствующий компонент и запускает его, руководствуясь глобальными настройками безопасности этого компонента.

Ключевым параметром здесь является настройка «Удостоверение» (Identity) для компонента Microsoft Excel в системе DCOM. В Windows предусмотрено несколько режимов определения учетной записи, под которой будет работать запущенный COM-объект:

  1. Интерактивный пользователь (The Interactive User). При этой настройке DCOM-сервер (в нашем случае Excel) всегда запускается в сессии и под учетной записью того пользователя, который в данный момент вошел в систему интерактивно (через физическую консоль или RDP). Если в системе сейчас авторизован администратор, Excel запустится под администратором прямо на его рабочем столе. Если на сервере никто не авторизован, вызов COM-объекта завершится критической ошибкой.
  2. Запускающий пользователь (The Launching User). В этом режиме процесс запускается под той же учетной записью, от имени которой работает вызывающее приложение. Для регламентного задания 1С это будет служебный аккаунт User1Cv82. Процесс будет выполняться в неинтерактивной (скрытой) сессии (Session 0).
  3. Указанный пользователь (This User). Система всегда запускает COM-объект под строго определенной учетной записью, имя и пароль которой жестко прописаны в настройках компонента.

По умолчанию или в результате определенных системных сбоев для Microsoft Excel может быть установлен режим «Интерактивный пользователь». Именно это и приводит к тому, что фоновое задание 1С активирует Excel в сеансе текущего администратора.

Влияние перехода на 64-разрядные версии

Часто системные администраторы замечают, что данная проблема проявляется сразу после перевода платформы 1С:Предприятие и пакета Microsoft Office с 32-битной (x86) на 64-битную (x64) архитектуру. Этому есть четкое техническое объяснение.

В 64-битных версиях операционных систем Windows настройки DCOM разделены на две независимые ветки:

Когда вы использовали 32-битную платформу 1С и 32-битный Excel, система обращалась к одной ветке DCOM, где права доступа и удостоверение могли быть настроены корректно (или настроены годами ранее). После обновления программного обеспечения до 64 бит сервер 1С стал обращаться к 64-битному системному реестру и соответствующей ветке DCOM, где параметры безопасности для Microsoft Excel по умолчанию сброшены или установлены в небезопасный интерактивный режим.

---

Пошаговое руководство по исправлению проблемы

Для того чтобы вернуть процесс Excel в скрытый режим работы под учетной записью службы 1С, нам потребуется выполнить комплексную настройку безопасности операционной системы.

Шаг 1. Настройка компонента DCOM Microsoft Excel

Выполним перенастройку удостоверения запуска для Excel:

  1. Нажмите на сервере комбинацию клавиш Win + R, введите команду dcomcnfg и нажмите Enter.
  2. В открывшемся окне «Службы компонентов» перейдите по дереву: Службы компонентов -> Компьютеры -> Мой компьютер -> Настройка DCOM.
  3. Найдите в списке элемент с именем Microsoft Excel Application (или Microsoft Excel Document).
  4. Если этого элемента нет в списке (такое часто бывает в 64-битных системах), его необходимо зарегистрировать. Для этого откройте редактор реестра regedit, найдите ветку HKEY_CLASSES_ROOT\AppID\EXCEL.EXE и убедитесь в наличии строкового параметра AppID со значением {00020812-0000-0000-C000-000000000046}. Если раздела или параметра нет, создайте их вручную, после чего перезапустите консоль dcomcnfg.
  5. Нажмите правой кнопкой мыши по компоненту Microsoft Excel Application и выберите пункт Свойства.
  6. Перейдите на вкладку Удостоверение (Identity).
  7. Переключите тумблер с положения «Интерактивный пользователь» на положение «Запускающий пользователь» (The Launching User). Если вы хотите, чтобы Excel всегда работал под строго определенной учетной записью, выберите «Указанный пользователь» и введите реквизиты служебной учетной записи.
  8. Перейдите на вкладку Безопасность (Security). В разделах «Разрешения на запуск и активацию» и «Разрешения на доступ» выберите пункт «Настроить» (Customize), нажмите кнопку «Изменить» и добавьте туда учетную запись, под которой работает служба сервера 1С (в нашем примере — User1Cv82), предоставив ей полные права.
  9. Нажмите кнопку Применить и закройте консоль.

Шаг 2. Создание системных папок Desktop (Критически важно!)

После того как вы переключили запуск Excel в режим «Запускающий пользователь», Excel начнет запускаться в изолированной неинтерактивной сессии под учетной записью службы 1С. Однако здесь вас подстерегает следующая классическая ошибка автоматизации Office: Excel будет аварийно завершать работу при попытке выполнить метод SaveAs.

Это связано с тем, что для инициализации принтеров и виртуального рабочего стола продуктам MS Office жизненно необходима папка Desktop в профиле пользователя, под которым запускается служба. У системных учетных записей этой папки по умолчанию нет.

Для исправления этой ошибки создайте вручную следующие директории на сервере:

После создания папок обязательно нажмите по ним правой кнопкой мыши, зайдите в свойства безопасности и предоставьте полные права доступа (Full Control) для учетной записи службы сервера 1С (User1Cv82).

---

Альтернативные и более надежные архитектурные решения

Хотя настройка DCOM решает сиюминутную проблему, использование Microsoft Office на стороне сервера в неинтерактивных сессиях (в службах Windows) официально не поддерживается компанией Microsoft. Серверный запуск Excel часто приводит к утечкам оперативной памяти, зависанию процессов excel.exe в диспетчере задач и блокировкам файлов.

Рассмотрим, как можно оптимизировать этот процесс и полностью отказаться от использования нестабильного COM-соединения.

1. Оптимизация встроенного конвертера PDF в 1С

В сообщениях темы упоминалось, что при сохранении табличного документа штатными средствами 1С в PDF размер файла получается избыточным (порядка 40 Мб вместо 400 Кб в Excel). Это происходит по двум причинам:

Пример стандартного кода конвертации табличного документа в PDF средствами платформы 1С без привлечения сторонних приложений:


ТабДок = Новый ТабличныйДокумент;
// Заполнение табличного документа данными отчета...
// ...
ТабДок.Записать(ПутьКФайлуPdf, ТипФайлаТабличногоДокумента.PDF);

2. Использование внешних утилит и библиотек

Если вам все же необходимо формировать файлы формата XLSX высокой сложности, рассмотрите возможность использования внешних кроссплатформенных библиотек, не требующих установки MS Office на сервере:


ПараметрыЗапуска = "--headless --convert-to pdf --outdir ""C:\Temp"" ""C:\Temp\report.xlsx""";
ЗапуститьПриложение("C:\Program Files\LibreOffice\program\soffice.exe " + ПараметрыЗапуска, , Истина);

Этот способ работает стабильно, полностью изолирован от пользовательских сессий RDP и не требует сложной настройки системных служб DCOM.

Подводя итог, отметим: если перед вами стоит задача быстрого исправления текущей работающей конфигурации — воспользуйтесь пошаговой инструкцией по настройке DCOM и созданию системных папок Desktop. Если же вы проектируете систему «с нуля», откажитесь от использования COM-объектов MS Office на сервере в пользу штатных механизмов 1С или свободно распространяемых консольных конвертеров.

← На главную