При работе с сервером 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-объект:
User1Cv82. Процесс будет выполняться в неинтерактивной (скрытой) сессии (Session 0).По умолчанию или в результате определенных системных сбоев для Microsoft Excel может быть установлен режим «Интерактивный пользователь». Именно это и приводит к тому, что фоновое задание 1С активирует Excel в сеансе текущего администратора.
Часто системные администраторы замечают, что данная проблема проявляется сразу после перевода платформы 1С:Предприятие и пакета Microsoft Office с 32-битной (x86) на 64-битную (x64) архитектуру. Этому есть четкое техническое объяснение.
В 64-битных версиях операционных систем Windows настройки DCOM разделены на две независимые ветки:
mmc comexp.msc /32dcomcnfgКогда вы использовали 32-битную платформу 1С и 32-битный Excel, система обращалась к одной ветке DCOM, где права доступа и удостоверение могли быть настроены корректно (или настроены годами ранее). После обновления программного обеспечения до 64 бит сервер 1С стал обращаться к 64-битному системному реестру и соответствующей ветке DCOM, где параметры безопасности для Microsoft Excel по умолчанию сброшены или установлены в небезопасный интерактивный режим.
---
Для того чтобы вернуть процесс Excel в скрытый режим работы под учетной записью службы 1С, нам потребуется выполнить комплексную настройку безопасности операционной системы.
Выполним перенастройку удостоверения запуска для Excel:
Win + R, введите команду dcomcnfg и нажмите Enter.regedit, найдите ветку HKEY_CLASSES_ROOT\AppID\EXCEL.EXE и убедитесь в наличии строкового параметра AppID со значением {00020812-0000-0000-C000-000000000046}. Если раздела или параметра нет, создайте их вручную, после чего перезапустите консоль dcomcnfg.User1Cv82), предоставив ей полные права.После того как вы переключили запуск Excel в режим «Запускающий пользователь», Excel начнет запускаться в изолированной неинтерактивной сессии под учетной записью службы 1С. Однако здесь вас подстерегает следующая классическая ошибка автоматизации Office: Excel будет аварийно завершать работу при попытке выполнить метод SaveAs.
Это связано с тем, что для инициализации принтеров и виртуального рабочего стола продуктам MS Office жизненно необходима папка Desktop в профиле пользователя, под которым запускается служба. У системных учетных записей этой папки по умолчанию нет.
Для исправления этой ошибки создайте вручную следующие директории на сервере:
C:\Windows\SysWOW64\config\systemprofile\DesktopC:\Windows\System32\config\systemprofile\DesktopПосле создания папок обязательно нажмите по ним правой кнопкой мыши, зайдите в свойства безопасности и предоставьте полные права доступа (Full Control) для учетной записи службы сервера 1С (User1Cv82).
---
Хотя настройка DCOM решает сиюминутную проблему, использование Microsoft Office на стороне сервера в неинтерактивных сессиях (в службах Windows) официально не поддерживается компанией Microsoft. Серверный запуск Excel часто приводит к утечкам оперативной памяти, зависанию процессов excel.exe в диспетчере задач и блокировкам файлов.
Рассмотрим, как можно оптимизировать этот процесс и полностью отказаться от использования нестабильного COM-соединения.
В сообщениях темы упоминалось, что при сохранении табличного документа штатными средствами 1С в PDF размер файла получается избыточным (порядка 40 Мб вместо 400 Кб в Excel). Это происходит по двум причинам:
Пример стандартного кода конвертации табличного документа в PDF средствами платформы 1С без привлечения сторонних приложений:
ТабДок = Новый ТабличныйДокумент;
// Заполнение табличного документа данными отчета...
// ...
ТабДок.Записать(ПутьКФайлуPdf, ТипФайлаТабличногоДокумента.PDF);
Если вам все же необходимо формировать файлы формата XLSX высокой сложности, рассмотрите возможность использования внешних кроссплатформенных библиотек, не требующих установки MS Office на сервере:
EPPlus или ClosedXML, напрямую из 1С через механизмы работы с внешними компонентами или посредством интеграции с кодом на C#. Они работают невероятно быстро, не зависают в памяти и генерируют файлы идеального качества и размера.
ПараметрыЗапуска = "--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С или свободно распространяемых консольных конвертеров.