I created a simple powershell script that will create an excel instance and save a workbook:
$excel = New-Object -ComObject Excel.Application
$workbook = $excel.Workbooks.Open("C:\Test\foo.xls")
$workbook.SaveAs("C:\Test\bar.xls")
# cleanup code ...
When I run this from powershell directly it works fine.
I created a scheduled task that runs it, and when I have the option set that will "Run only when the user is logged in" then it will run fine.
When I change this option to run whether the user is logged in or not, it will fail trying to open/save the file. The account I am using has the correct permissions. I have the account set up to Log in as a service.
Any suggestions?
I've been burned by this and didn't want to rewrite the code. I saw your post and several others which made me about to give up. However, my persistence paid off. I was trying to have Jenkins run a script to inventory our production environment and output to Excel. I didnt want a text doc because I was highlighting software versions that didnt match in RED, so needed Excel.
Here is the answer that worked for me:
You have to create a folder (or two on a 64bit-windows):
(32Bit, always)
C:\Windows\System32\config\systemprofile\Desktop
(64Bit)
C:\Windows\SysWOW64\config\systemprofile\Desktop
Link that someone provided as the source:
http://www.patton-tech.com/2012/05/printing-from-scheduled-task-as.html
My source was:
http://social.technet.microsoft.com/Forums/en/winserverpowershell/thread/aede572b-4c1f-4729-bc9d-899fed5fad02
I remember having to do something similar in a C# application, which went well when you build it on Visual Studio, but running under a service on the CI server failed. This I believe is the limitation of Office Automation itself and Microsoft doesn't recommend / support doing this at all Look at Considerations for server-side Automation of Office here - http://support.microsoft.com/kb/257757. It shows the problems and the alternatives.
In my case, I had to give up Office Interop, and use EPPlus ( http://epplus.codeplex.com/ ) to work with excel. It worked great and was much faster as well.
Related
I have a script which checks a folder for excel files and then if this "threshold" is greater than 0 then a macro from another excel file is run that interact with these excel folders.
When I run the process manually through powershell ISE it works fine but when I use the windows task scheduler the powershell script runs but the excel macro called doesn't run. Any suggestions why this might be the case? This process used to run on a windows 2008 server fine but was migrated to windows server 2012 and won't run properly
if ($count -gt $threshold){
$excel = new-object -comobject excel.application
$workbook = $excel.workbooks.open("D:\TimesheetService\IS-FS - AutoTimesheetLoader v2.3 - UAT.xlsm")
$worksheet = $workbook.worksheets.item(1)
$excel.Run("ImportTime")
$workbook.close($false)
$excel.quit()
[System.Runtime.Interopservices.Marshal]::ReleaseComObject($excel)
Remove-Variable excel
}
You cannot use the COM Automation Excel library (new-object -comobject excel.application) from a scheduled task, unless that task is run in the window station (session) of the currently logged-on user.
That is, in order to use the COM Excel library from a scheduled task, you must have the Run only when user is logged on option chosen for it, which you may not want, for two reasons:
It restricts your task to run only when someone happens to be logged on.
The currently logged-on user will see the task's window as it runs - unless you take extra steps to hide it (which can't be done with powershell.exe itself).
Note: There is a workaround that is currently effective, but it is unsupported, which is why it is better to avoid it - see this answer to a related superuser.com question.
Therefore, consider alternatives that do not have this restriction, such as the DocumentFormat.OpenXml Nuget package.
See this Microsoft support article for background information.
I was trying to do the same thing. This got it working for me https://www.jonashendrickx.com/2016/04/07/when-run-as-scheduled-task-excel-wont-save-with-powershell/
The last two steps is what I needed. Check to make sure these folders exist
On a 32-bit and 64-bit operating system:
C:\Windows\System32\config\systemprofile\Desktop
On a 64-bit operating system:
C:\Windows\SysWOW64\config\systemprofile\Desktop
I have created an agent iin which I call a dll file so that I can get data from another system eventually..
When I manually run this agent then the call to the dll file works and I get data from it.
When I call this agent from a browser then I get:
Error Description : Cannot create automation object
The security of the agent is on 3.Allow restricted operations with full administration rights.
Any idea why I get Cannot create automation object when running agent from browser?
When you start the agent from browser then the agent runs on Domino server.
So, you need to install automation object's software on this server.
When you manually run the agent then the code is executed on your client. This works because you installed the software necessary for creating the automation object on your client.
I found the same error but in my case everything was working properly until we restored a backup of Windows. The issue was caused because Office had to be reactivated again.
Sometimes this happens too because a corruption of the Word document, so you have to rebuild it.
I hope this could be helpful in future to other people
I'm currently working on automating a powershell script to make a dump of a small DB.
The database is accessible through a company Sharepoint and I am leveraging an IQY file exported from said Sharepoint to read the database contents.
When I run the script manually (i.e. calling it from the command line), it works with no issues, but when I try and start the script from Task Scheduler, the following exception is raised:
System.Reflection.TargetInvocationException
the line that is generating the exception is:
$iqy = $xl.Workbooks.Open($query, 2, $true)
Where $xl is a new Excel.Application ComObject, created correctly and $query is a string containing the full file path of the iqy file.
As for my configuration, I'm trying to run my script on a Windows Server 2008R2, using a local administrator user (same user that is supposed to launch the scheduled script), which is also authorized to access the Sharepoint. I'm running Powershell 3.0. I'm not loading any Sharepoint-related snapins.
The only answers I found poking around hinted at granting "Trust" to the IQY file location and the Sharepoint itself in Excel. That did not help.
The Exception also seems to point at a sharepoint issue, but since the script runs fine when started manually, I cannot understand how it could be anything to do with Sharepoint.
Am I missing some intricacy of the Task Scheduler?
Any help would be greatly appreciated.
Never mind, I seem to have found an answer.
If anyone is encountering the same issue, it appear the Excel Com Object has a bug that does not allow it to run from the Task Scheduler if you set it to run regardless of whether the user is logged in.
To circumvent that create the following 2 folders on the machine where the script is supposed to run:
(32Bit, always)
C:\Windows\System32\config\systemprofile\Dektop
(64Bit)
C:\Windows\SysWOW64\config\systemprofile\Desktop
After creating the folders, it worked as expected.
Source: http://social.technet.microsoft.com/Forums/windowsserver/en-US/aede572b-4c1f-4729-bc9d-899fed5fad02/run-powershell-script-as-scheduled-task-that-uses-excel-com-object?forum=winserverpowershell
we have a web service hosted on iis 6.0, it open a specify excel template file. And a macro "t.xla" should retrieve data from database after excel opened, ready for client to download.
The issue is that the macro seems not run. The code is like following (i'm not in company now, so i just write pseudocode):
System.Diagnostics.ProcessStartInfo pStartInfo = new ProcessStartInfo(excelAppPath, excelTemplatePath);
//nomal window is in debug mode, createNoWindow will be used in product envirionment
pStartInfo.WindowStyle = ProcessWindowStyle.Nomal;
System.Diagnostics.Process process = new Process();
process.Start(pStartInfo);
log.Info("Excel Process was started");
when i running this code,
1)could see excel.exe was started from task manager.
2)excel.exe creates no window on the desktop, someone says it should be, because of the iis limited.
3)I'm sure that the macro "t.xla" hadn't run, because there is no log exist which should be written by macro.When i doubleclick any one of the excel template, logs will be found.
Now iis worker process is run in local SYSTEM account , and already Enable IIS Admin Service to interact with desktop. Also the directory which the template file and log file in could be written by everyone
Could anyone give me some advise? Thanks in advance.
You might want to use another account other than local system -- that way you can log in as that account and try the same thing to see if any dialogs or errors are popping up that might be preventing things from moving further along, such as macro security settings. Microsoft does not support running Excel in this manner, but that doesn't mean you can't get it work. Check out this article, it covers many more details to consider: http://support.microsoft.com/kb/257757
Does anyone know if I NEED To wrap my Office 2007, vsto-based add-in in a MSI? It seems to be a lot of extra overhead and headache, just to have it not work anyway.
When I do get it to install, I still need to run the vsto installer, even though I have tried to use the |vstolocal switch to keep the add-in's deployment centralized.
Has anyone pulled this kind of install off successfully?
I've deployed VSTO from SCCM without using an MSI.
The trick is a simple command line:
"%commonprogramfiles%/microsoft shared/VSTO/10.0/VSTOInstaller.exe" /i <path to vsto>
VSTOInstaller.exe [[/install ] | [/uninstall ]] [/silent]
[/help]
/install, /i: Install the solution. This option must be followed by
the fully qualified path of a deployment manifest in the form http://,
https://, or \servername\foldername.
/uninstall, /u: Uninstall the solution. This option must be followed
by the fully qualified path of a deployment manifest in the form
http://, https://, or \servername\foldername.
/silent, /s: Install or uninstall without prompting for input or
providing information.
/help, /?: Generate this help message.
EXAMPLE: VSTOInstaller.exe /i \servername\foldername\AddIn.vsto
Be aware that with the /silent option "trust for the addin has to be built into the project or it will default to 'don't install' when using the silent switch." (source: TechNet post)
I've tried it, and you don't need to wrap it in an MSI if you're happy for users to manually install it. If you:
use the publish tab in project -> properties
setup your "publishing folder location" and "installation folder URL" properly
set and all of the other meta-data properly, including stuff in your AssemblyInfo.cs file
whack the "publish now" button
share out the installation folder and email out the link
ensure that users have the right permissions to install it (local admin I guess, you'd need to check)
It worked for me. On Windows 7 and XP too.
The whole "this publisher is untrusted" thing is a complete mess, trying to fix that involves writing some really stupid code that tells Windows that "hey, by the way, I am actually trusted". I didn't bother and just told people to ignore the warning.
I'm guessing that you only need an MSI if you want to push out the add-in using active directory and do an automated install.