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
Related
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 have written a Powershell script and it is saved in a .ps1 file. It only works with the 32-bit version of the Powershell that is located in
%SystemRoot%\syswow64\WindowsPowerShell\v1.0\powershell.exe
The script works when I run it manually but it is not run via Windows Task Scheduler. I am running the task as the same user that runs the script. In the Action part of my task I put the above address as Program/script and I write the full path of my .ps1 file as Add Arguments (optional). But it does not seem to work. I have also tried with putting the parent folder of my .ps1 file as Start in value to no avail.
How can I tell Task Scheduler to run my Powershell script using the 32-bit version?
UPDATE: I have to add here that my script actually opens an Excel file, refreshes it and then closes it. I know that using Excel in a non-interactive environment is a bad idea. But I still don't know if this is the reason my script is not run.
Highly suspect Excel is the reason this appears not to work. Have your script do something non-Excel (e.g. create file) and check if this part was executed fine
Two major gotchas I've come across when automating Excel:
Create empty folders if they don't exist (excel automation bug)
Ensure DCOM security settings are configured to allow Excel to run. This is still required if you are running task as same user who manually runs script.
When DCOM permissions are not set correctly and running the script as an automated task, you will get the below error. Saw this as session was transcribed, and transcription output to text file.
New-Object : Retrieving the COM class factory for component with CLSID
{00024500-0000-0000-C000-000000000046} failed due to the following
error: 80070005 Access is denied. (Exception from HRESULT: 0x80070005
(E_ACCESSDENIED)).
You could adopt your script to determine the current powershell version and invoke the same script with the 32bit version if necessary. Put these lines on the top of your script:
# ensure the script is running with the 32bit powershell
if ($env:Processor_Architecture -ne "x86")
{
$psx86 = Join-Path $env:SystemRoot '\syswow64\WindowsPowerShell\v1.0\powershell.exe'
& $psx86 -noprofile -file $myinvocation.Mycommand.path -executionpolicy bypass
exit
}
Note: You can append parameter to the powershell invoke in case your script requires them.
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
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.
I have been looking at an issue for a week straight and have been unable to figure it out and I am desperate for the fix.
On a client site, we have two environments: UAT and PROD. UAT works perfect (Please keep this in mind). We are now trying to deploy the solution to PROD but certain parts of the solution are not working.
We have developed an asp.net application that we provide to clients to allow them to invoke SSIS packages (there are a couple of drop downs that they first select then click a button named "invoke").
When the user clicks the Invoke button, a batch file named InvokeSSIS.bat is called that assembles a command line call to dtexec with the appropriate parameters.
I'm having a problem with a particular package that is responsible for calling an executable which generates a spreadsheet that i will be importing into my system.
The executable is on an mapped H:\ drive.
I have modified the InvokeSSIS.bat batch file to capture the command the batch file is generating. If I execute this command from the command line, it works perfectly. From the webapp Invoker, it executes the package but the tasks responsible for calling the executable doesn't execute as the entire package takes only 1 second to complete (whereas it should take about a minute.)
The executable DOES have a GUI, but it is NOT interactive. This is because when you call the GUI with specific parameters, it automatically runs in batch mode and executes a macro used to generate the desired spreadsheet.
I know this is ok because it works on the UAT server AND it works from the command line!
I have checked the permissions on the executable (bu right-clicking the executable and clicking properties.) I have granted Full Control on the executable to the same user specified as the identity tab of the application pool i am using.
Can someone please help me? As I said I am dying over here!
Please let me know if you have any ideas or what other info you need.
Environment (both UAT and PROD)
OS: Windows Server 2003
IIS 6
asp.net 2.0
SQL Server 2008
Thanks!
Steve
You can't use a mapped drive with IIS.
You must use the \\servername syntax to reach files on other systems.
I agree with user544284 that this is at least in part a mapping issue. I'll ignore for a minute the complete insanity of having a web application call a batch file to start an executable that's on a remote network drive through a drive letter mapping.
Most likely the UAT box has something set up that maps that drive letter for you which Prod is missing.
The only other possibility is a security violation is occurring. Running .exe's from a network drive is generally frowned on. Do the two environments have the exact same version of windows? Are they configured the same with regards to UAC? Any differences here are going to be important.
Which brings up an interesting thought. I wonder if someone logged in to the UAT server using the same account credentials the app pool is using and added the ip address of the machine where the exe lives to the list of "Local Intranet" sites... Or, if they installed SSIS on the UAT server itself.
Just because YOU can log in to the server and run it on the command line means nothing. You have to find out if the drive letter is mapped at all for the user that the web app is running under and whether that user has the required security bits and whether the local OS will allow it regardless.
Okay, I can't ignore it: hairbrained is the nicest adjective I can come up with for this "architecture". Do yourself a favor and go back to the drawing board on this one. It has the word "brittle" written all over it, as you have already found. Instead of building out a batch file to call dtexec, just do it directly either by something like this or this.