0

I have inherited a C# program that used to automate the creation of a daily report on Windows XP Pro SP3 using PDFCreator 1.2.3, MapInfo Professional 11, Word 2003, and Excel 2003. This Win XP machine was in an Active Directory domain and the C# program ran as a domain user (with Administrative permissions) with the user logged in and the desktop locked. Word 2003 was automated to open a template, create a document from the template, and save the document--all from/on a network share. Excel 2003 was used to open a spreadsheet with a table linked to an ODBC datasource and refresh the table, pulling the new data into the spreadsheet. MapInfo was used to generate map images from an ODBC datasource. PDFCreator was used to take the spreadsheet, word document, and images and put them all together into a daily report.

As XP has reached its end-of-life I have moved this program to a Win 8.1 EE virtual machine (in the same domain) and have installed Office 365 products (Word 2013 and Excel 2013) along with PDFCreator 1.7.1 and MapInfo Professional 12 to use in automating the creation of this daily report. This program works normally when run manually on the new VM, but fails when run as the same user as a Scheduled Task. This scheduled task is set to run with the highest permissions and run if the user is not logged in.

I realize there are many variables at play here; the O/S had to change and we don't use the old version of Office anymore, I also couldn't get older versions of PDFCreator or MapInfo. Therefore, I will focus the question on the things I can control. I am aware of the problems I face in doing this but am not clear on whether or not this is actually possible to do now given the new O/S and applications (namely Word 2013 and Excel 2013) that I have been asked to try to make it work with.

So, the question is: How can Word 2013 be automated from a C# Interop/COM program using Task Scheduler to run the program with a user logged on and the desktop locked?

RGS
  • 77
  • 2
  • 9
  • Yes, but that's been true for a long time. Google .net office automation. Suspect that interactive was being used to solve things like shares and such. – Tony Hopkinson Apr 14 '14 at 13:29
  • Do you have the source code to the C# program? – Black Frog Apr 14 '14 at 13:37
  • I've googled and read until my eyes were bloodshot red. I didn't see a way to do what I'm trying to do through Task Scheduler. I'll need to revise my question. – RGS Apr 14 '14 at 13:40
  • Yes Black Frog, I have the source. – RGS Apr 14 '14 at 13:41
  • I would recommend you compile the application against [Office 2013 Primary Interop Assembly](http://msdn.microsoft.com/en-us/library/office/ff597925(v=office.15).aspx) References. – Black Frog Apr 14 '14 at 13:45
  • Tony, this worked normally on Win XP Pro SP3 before being moved to a Win 8.1 EE machine. Are you suggesting that Win 8.1 isn't loading network shares for a user who is logged on but has the desktop locked? – RGS Apr 14 '14 at 13:46
  • In the local security policy have you set your test user to allow them to log on as a batch job or a service? – Nanhydrin Apr 14 '14 at 13:47
  • Black Frog, the program is currently complied in that manner. – RGS Apr 14 '14 at 13:48
  • Question revised due to establishing that the session is, in fact, interactive based on an answer provided by Black Frog. – RGS Apr 14 '14 at 14:25

2 Answers2

1

From Microsoft Docs - Considerations for server-side Automation of Office:

All current versions of Microsoft Office were designed, tested, and configured to run as end-user products on a client workstation. They assume an interactive desktop and user profile. They do not provide the level of reentrancy or security that is necessary to meet the needs of server-side components that are designed to run unattended.

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.

I know it doesn't answer the question about Office 365, but I think this is as close as you are going to get. Also I found this article: HOWTO: Configure Office Applications to Run Under the Interactive User Account.

Community
  • 1
  • 1
Black Frog
  • 11,595
  • 1
  • 35
  • 66
  • Considering that the user the task is supposed to run as is currently logged on (but with the desktop locked), would you still say that Office is being run without an interactive desktop and user profile? In other words, does having an interactive desktop and user profile absolutely require that the user not have the desktop locked? I'm just trying to be 100% certain on the definition of an interactive session and user profile. – RGS Apr 14 '14 at 14:02
  • If the user is logon on, the desktop is locked, you have an interactive session. – Black Frog Apr 14 '14 at 14:11
  • Given that, I should then have an interactive session thereby rendering the answer you provided null. – RGS Apr 14 '14 at 14:16
0

The answer, I have found, is that a task such as this one when run on Windows XP Pro SP3 with the options selected to run as Administrator and to run whether logged on or not were not able to be used with the same task/user/permissions under Windows 8.1 EE.

The task ran successfully with the options to run as Administrator and run if not logged on being not selected.

For anyone else migrating legacy programs/tasks from Win XP as they decommission due to end-of-life, you may want to try removing the run as Administrator and run if not logged on options on the task in the new version of Windows Task Scheduler.

RGS
  • 77
  • 2
  • 9