S
sm_gardiner
I have a VB.NET windows service that executes this line of code to return a
UNTYPED excel application object (it is untyped because we use a mixture of
versions of office).
<code>
excelApp = CreateObject("Excel.Application")
</code>
This does not work when the service is running as local SYSTEM account but
is OK if the service logs on as a domain Administrator account. If I allow
the SYSTEM service to interact with the desktop I see Excel error boxes, but
no useful error info. If i don't allow interaction, then the serivce hangs up
for 25 seconds or so.
The office version is 2003 and the OS is windows server 2003 sp1 standard
edition. There are no problems running the application normally.
I know this executes OK on another very similar server that uses office 2000
under the local SYSTEM account, but I can't find any differences in the COM
or .NET security settings, but I might be missing something. Also, this might
be a red herring, but I've recently installed some updates on the new server
and it's possible that this has interfered in the process.
I do have the admin user workaround, but I'd be interested in making it work
with SYSTEM as this service gets redeployed by an automatic system that will
be unable to set the service log on.
UNTYPED excel application object (it is untyped because we use a mixture of
versions of office).
<code>
excelApp = CreateObject("Excel.Application")
</code>
This does not work when the service is running as local SYSTEM account but
is OK if the service logs on as a domain Administrator account. If I allow
the SYSTEM service to interact with the desktop I see Excel error boxes, but
no useful error info. If i don't allow interaction, then the serivce hangs up
for 25 seconds or so.
The office version is 2003 and the OS is windows server 2003 sp1 standard
edition. There are no problems running the application normally.
I know this executes OK on another very similar server that uses office 2000
under the local SYSTEM account, but I can't find any differences in the COM
or .NET security settings, but I might be missing something. Also, this might
be a red herring, but I've recently installed some updates on the new server
and it's possible that this has interfered in the process.
I do have the admin user workaround, but I'd be interested in making it work
with SYSTEM as this service gets redeployed by an automatic system that will
be unable to set the service log on.