[gl00mie]

Если вдруг кому взбредет в голову запускать AOS под непривилегированным пользователем и создавать на нем файлы Excel - так, чтобы Excel запускался на сервере, то его ждут новые приключения, связанные с правами доступа. Для теста я использовал простой джобик:

SysExcelApplication xl;
SysExcelWorkbook    wbk;
;
xl = SysExcelApplication_NET::construct( ClassRunMode::Server );
xl.visible( false );
wbk = xl.workbooks().add();
wbk.saveAs( DEV_xInfoDirectoryServer( DirectoryType::Temp ) + 'test.xls' );
xl.quit();

Здесь:

• SysExcelApplication_NET - это переписанная на .NET обертка для работы с Excel, умеющая работать в т.ч. на сервере, см. тему Взаимодействие с Excel через .NET (семейство классов SysExcel)
• DEV_xInfoDirectoryServer - обертка для xInfo::directory() в Global, выполняемая явно на сервере и возвращающая пути такими, как их видит AOS

Так вот, первое, с чем приходится столкнуться, - это что создание экземпляра SysExcelApplication_NET на сервере валится с ошибкой, при этом в eventlog создается сообщение вида

Цитата:

The machine-default permission settings do not grant Local Activation permission for the COM Server application with CLSID {00024500-0000-0000-C000-000000000046} and APPID Unavailable to the user DOMAIN\AX2009AosUser from address LocalHost (Using LRPC). This security permission can be modified using the Component Services administrative tool.

Все бы хорошо, но в апплете Component Services ни разу не видать чего-либо, похожего на CLSID {00024500-0000-0000-C000-000000000046}.

ШАГ 1. Идем в редактор реестра и добавляем туда что-то вроде этого (ветка HKCR\CLSID\{00024500-0000-0000-C000-000000000046} там уже есть):

REGEDIT4

[HKEY_CLASSES_ROOT\CLSID\{00024500-0000-0000-C000-000000000046}]
"AppID"="{00024500-0000-0000-C000-000000000046}"

[HKEY_CLASSES_ROOT\AppID\{00024500-0000-0000-C000-000000000046}]
@="Microsoft Excel"

Теперь в Component Services\Computers\My Computer\DCOM Config мы видим "Microsoft Excel" и можем специально для него добавить права (Local Access, Local Launch, Local Activation) для группы, в которой собраны учетные записи AOS'ов:

Здесь я исхожу из того, что на вкладке Identity мы выбрали запуск DCOM-сервера под тем пользователем, который собственно его запускает (The launching user) - это логично, раз мы решили ограничить права самого AOS'а.
Теперь как минимум экземпляр SysExcelApplication_NET у нас создается, и под тем пользователем, под которым работает AOS, запускается процесс Excel.exe. Однако, на строке добавления новой книги Excel у нас вылетает исключение Exception::CLRError без какого-либо текста сообщения. Его причина заключается в том, что Excel хоть и запускается под нашим непривилегированным пользователем, но пытается получить доступ на изменение к ряду каталогов в %SystemRoot%\SysWOW64\config\systemprofile.

ШАГ 2. На каталоги

Цитата:

%SystemRoot%\SysWOW64\config\systemprofile\AppData\Local\Microsoft\Windows\Temporary Internet Files
%SystemRoot%\SysWOW64\config\systemprofile\Desktop

добавляем права на изменение для группы, в которой собраны учетные записи AOS'ов. Теперь тестовый джобик успешно отрабатывает: на сервере запускается Excel, создает новый файл и сохраняет его во временном каталоге приложения.