SSIS Package will only run as SQL Agent Job when I have remote desktop to server open.

Question

Hey guys, so I have another problem to add to the already massive 'SSIS/SQL Server Agent Job' pile. After days of searching, I can't seem to find anything specific to my problem though.
The setup is as follows: a SSIS package that refreshes and saves excel files that are hosted on a server. The package runs fine on the local machine, using BIDS on the server, and will even work as a SQL Agent Job on the server IF there is a remote
desktop connection to the server. To elaborate, if I simply run the job as you would normally do it will fail and give the below error. If I run the job while either myself, or a different machine, has a remote desktop connection to the server where the
job is scheduled - it will run successfully.
Below is the error from the History File of the job. Any help would be greatly appreciated.
  Source: Refresh Excel and Save      Description: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Runtime.InteropServices.COMException (0x8000401A): Retrieving
the COM class factory for component with CLSID {00024500-0000-0000-C000-000000000046} failed due to the following error: 8000401a.     at ST_79772452677f4de1852d5ffbba3e5232.csproj.ScriptMain.ExcelRefresh(String FileName)    
at ST_79772452677f4de1852d5ffbba3e5232.csproj.ScriptMain.Main()     --- End of inner exception stack trace ---     at System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object[] arguments, SignatureStruct&
sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)     at System.RuntimeMethodHandle.InvokeMethodFast(Object target, Object[] arguments, Signature sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)    
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks)     at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags
invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)     at System.RuntimeType.InvokeMember(String name, BindingFlags bindingFlags, Binder binder, Object target, Object[] providedArgs, ParameterModifier[] modifiers, CultureInfo
culture, String[] namedParams)     at System.Type.InvokeMember(String name, BindingFlags invokeAttr, Binder binder, Object target, Object[] args, CultureInfo culture)     at Microsoft.SqlServer.Dts.Tasks.ScriptTask.VSTATaskScriptingEngine.ExecuteScript()
UPDATE:
In my previous post the Identity in DCOM Config file for Microsoft Excel was set as The Interactive User. The job was working only when I had a remote connection to the server open.
If I set the Identity to 'This User' and use the username and password of the server login account, it will work as a scheduled job without needing an open remote connection to the server. So it works, great! but I have reservations setting this
for all instances of Excel for the server. I'm sure other users have different accounts they use for running Excel. Any suggestions around this?

Answer 1

Hi LiamSexton,
It should be the server-side Automation of Office issue described in the following KB article:
http://support.microsoft.com/kb/257757 
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit
unstable behavior and/or deadlock when Office is run in this environment.
User Identity: Office applications assume a user identity when the applications are run, even when Automation starts the applications. The applications try to initialize toolbars, menus, options, printers, and some add-ins based on settings in the user
registry hive for the user who launches the application. Many services run under accounts that have no user profiles (such as the SYSTEM account or the IWAM_[servername] accounts). Therefore, Office may not initialize correctly on startup. In this situation,
Office returns an error on the CreateObject function or the CoCreateInstance function. Even if the Office application can be started, other functions may not work correctly if no user profile exists.
To work around the issue, you can refer to the following alternative introduced in the article:
Most server-side Automation tasks involve document creation or editing. Office 2007 supports new Open XML file formats that let developers create, edit, read, and transform file content on the server side. These file formats use the System.IO.Package.IO
namespace in the Microsoft .NET 3.x Framework to edit Office files without using the Office client applications themselves. This is the recommended and supported method for handling changes to Office files from a service.
Regards,
Mike Yin
TechNet Community Support