I'm running a PowerShell script that converts a CSV file to Excel. When I run it manually it works fine, but when I run it through a scheduled task it fails. Here is the error I'm getting:
Exception calling "Open" with "1" argument(s): "Open method of Workbooks class
failed"
At C:\PowerShell\Weekly\WeeklyReport.ps1:337 char:34
+ $workbook = $excel.Workbooks.Open <<<< ($csvFilePath)
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : ComMethodTargetInvocation
I'm using the same account in the scheduled task as I am when logged in. I also had the scheduled task use the local administrator account, but still had the same issue. What I'm actually launching is a VB script, which in turn launches a .bat file, which lists out a few PowerShell scripts. The VB script is used to hide the window so it doesn't show up when it's running. If I manually run the VB script it runs fine, but when running it through scheduled task it fails with the error I listed. I'm using Windows Server 2008 and I have Office 2003 installed. Here is the portion of the PowerShell script that is failing:
$excel = New-Object -ComObject excel.application
$excel.visible = $False
$excel.displayalerts=$False
$workbook = $excel.Workbooks.Open($csvFilePath)
$workSheet = $workbook.worksheets.Item(1)
It's failing on the line
$workbook = $excel.Workbooks.Open($csvFilePath)
Any help would be greatly appreciated. Thank you!
Okay so I found my problem. I went into dcomcnfg. Since my application "Excel" was 32bit and I was running on a 64bit machine I had to lunch the 32 bit version of it:
c:\Windows\SysWOW64>mmc comexp.msc /32
Once I was in there I went into Component Services -> Computers -> My Computer -> DCOM Config. In that list I fond Microsoft Excel Application and went into properties. In the security tab I hit the radio box for "Customize" next to each one and hit the edit button for each one and added the user account I was lunching the scheduled task with. Full access to everything. Under "Identity" tab I hit the radio circle for "This user" and again put the information for the user I was running the task with. I probably didn't need to do all of that, I'm sure it only took one thing to fix the problem, but I wasn't sure which one to do so I did them all. And it worked.
Related
I suspect there may have been some change recently, either to my own work computer or my company's 365 subscription, that has alter the behavior of a frequently used script. Specifically, with this line:
emphasized textNew-Object -ComObject excel.application
Consistently, every time the script is run in full I receive this error:
New-Object : Creating an instance of the COM component with CLSID {00024500-0000-0000-C000-000000000046} from the IClassFactory failed due
to the following error: 80010108 The object invoked has disconnected from its clients. (Exception from HRESULT: 0x80010108
(RPC_E_DISCONNECTED)).
However, if I manually progress through he script regions at a time, although he line might fail initially, it will typically succeed the next.
I have tried debug to slow the process down, as well as adding a sleep time, with no joy.
Any ideas as to what may have changed? This script has run without issue for months until recently. My suspicion is that it's a timing/licensing issue. I will be getting a local Office installation as I have read of some successes in doing so, but this will not be viable solution, if it works, long term.
It looks like the available ressource handles are exhausted. Check this
Creating an instance of the COM component with CLSID
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
Edit : After a lots of testing, we managed to find a comon point between the machines which, when connected using RDP to our environment, breaked the excecution of excel funtionnalities called from a powershell script launched by an azure devops agent : All these machines have a touchscreen, machines without a touchscreen do not break it (tryed with 3 machines with touchscreen, different contructors and 4 machines without touchscreen)
Edit 2: When the touchscreen is disabled being connected to the machine with RDP do not break the script anymore
I'm using AzureDevops agents to execute a powershell task on a Cloud Hosted environment, the task is very simple it justs creates a workbook and saves it:
try{
write-host 'initalized excel'
$Excel = New-Object -ComObject Excel.Application
write-host 'adding WB'
$Workbook = $Excel.Workbooks.Add()
write-host 'Saving Wb'
$Workbook.SaveAs('C:\test\test.xlsx')
}
finally{
write-host 'quitting excel'
$Excel.quit()
}
Here's the output of the devops Task :
##[section]Starting: PowerShell Script
==============================================================================
Task : PowerShell
Description : Run a PowerShell script on Linux, macOS, or Windows
Version : 2.151.2
Author : Microsoft Corporation
Help : https://learn.microsoft.com/azure/devops/pipelines/tasks/utility/powershell
==============================================================================
Generating script.
========================== Starting Command Output ===========================
##[command]"C:\windows\System32\WindowsPowerShell\v1.0\powershell.exe" -NoLogo -NoProfile -NonInteractive -ExecutionPolicy Unrestricted -Command ". 'C:\agent\_work\_temp\33ed6d09-53ba-427a-a7ac-ea425a98767c.ps1'"
initalized excel
adding WB
quitting excel
Exception from HRESULT: 0x800A03EC
At C:\agent\_work\_temp\33ed6d09-53ba-427a-a7ac-ea425a98767c.ps1:6 char:5
+ $Workbook = $Excel.Workbooks.Add()
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (:) [], COMException
+ FullyQualifiedErrorId : System.Runtime.InteropServices.COMException
This is what happens when my colleague is connected to the virtual machine on which the agent executes the script. My colleague is connected with the windows remote desktop tool.
When I'm the one connected on the VM using RDP it works fine :
##[section]Starting: PowerShell Script
==============================================================================
Task : PowerShell
Description : Run a PowerShell script on Linux, macOS, or Windows
Version : 2.151.2
Author : Microsoft Corporation
Help : https://learn.microsoft.com/azure/devops/pipelines/tasks/utility/powershell
==============================================================================
Generating script.
========================== Starting Command Output ===========================
##[command]"C:\windows\System32\WindowsPowerShell\v1.0\powershell.exe" -NoLogo -NoProfile -NonInteractive -ExecutionPolicy Unrestricted -Command ". 'C:\agent\_work\_temp\436b2d56-2a41-4f75-97bb-01d4c41407e6.ps1'"
initalized excel
adding WB
Saving Wb
quitting excel
##[section]Finishing: PowerShell Script
My colleage and I RDP to the virtual machine with the same exact user.
We tried on another virtual machine with another devops agent, the same issue arise.
I'm a bit lost and I dont know how to troubleshoot this issue at all, also if you have any other suggestion for the title I'll take every piece of advice.
Edit:
We also tried to put this script in a loop and write if it succeed or fail, when I rdp to the virtual machine, it works, if I disconnect it works, as soon as my colleague RDP into the virtual machine it starts failing, if I reconnect (thus disconnecting my colleague) it works again. (We RDP with the same user)
Edit2 :
I'm receiving an edit suggestion from someone who noticed me that :
From the user's comment->' when the agent is already running and
creating excel files in a loop, the simple fact my colleague rdp to
the vm breaks the excel file creation.' This issue seems to have
nothing to do with azure devops. The reason for the problem is due to
rdp
Well it's an azure devops agent problem as well since simply running the script manually works for both of us. It's a RDP issue that cause the Devops agent to be unable to use some of the excel-powershell functions, so I think the Azure Devops tag is still accurate
Edit :
In the finally block try outputting the full error stack with: $Error
| Format-List -Force – HAL9256
Here's the error :
Exception : System.Runtime.InteropServices.COMException (0x800706BE): The remote procedure call failed.
(Exception from HRESULT: 0x800706BE)
at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode,
IntPtr errorInfo)
at System.Management.Automation.ComInterop.ComRuntimeHelpers.CheckThrowException(Int32
hresult, ExcepInfo& excepInfo, ComMethodDesc method, Object[] args, UInt32 argErr)
at CallSite.Target(Closure , CallSite , ComObject )
at System.Dynamic.UpdateDelegates.UpdateAndExecute1[T0,TRet](CallSite site, T0 arg0)
at CallSite.Target(Closure , CallSite , Object )
at System.Dynamic.UpdateDelegates.UpdateAndExecute1[T0,TRet](CallSite site, T0 arg0)
at System.Management.Automation.Interpreter.DynamicInstruction`2.Run(InterpretedFrame frame)
at
System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame
frame)
TargetObject :
CategoryInfo : OperationStopped: (:) [], COMException
FullyQualifiedErrorId : System.Runtime.InteropServices.COMException
ErrorDetails :
InvocationInfo : System.Management.Automation.InvocationInfo
ScriptStackTrace : at <ScriptBlock>, C:\agent\_work\_temp\fae3ef7a-700d-49c1-8f1f-7f7d2bc0d49e.ps1: line 8
at <ScriptBlock>, <No file>: line 1
PipelineIterationInfo : {}
PSMessageDetails :
Running Excel under an automated, unattended process (such as an Azure DevOps Agent) in unsupported and can lead to all kinds issues, like the ones you are running into.
The official recommendation is to rely on a 3rd party component like Excel Package Plus (free), NPOI (free), SpreadSheetGear (Commercial) or Aspose Cells.NET (Commercial). Or to use System.IO.Packaging and edit the XML for the Office document directly. These do not depend on having Excel installed on your server, are actually supported and don't have all kinds of license issues associated with them. Migrating your scrips over to these other package types is often not very hard, since they take a very similar API for portability.
Besides the technical issues you're running into, the licensing may be even hairier, as Office isn't allowed to be automated 'on behalf of other users' and generally isn't allowed to run on a server.
Besides the technical problems, you must also consider licensing issues. Current licensing guidelines prevent Office applications from being used on a server to service client requests, unless those clients themselves have licensed copies of Office. Using server-side Automation to provide Office functionality to unlicensed workstations is not covered by the End User License Agreement (EULA).
https://support.microsoft.com/en-us/help/257757/considerations-for-server-side-automation-of-office
You may be able to solve some of the issues, like the one you are experiencing now, but you're likely going to run into new ones. Running the Azure DevOps agent interactively may help, that way Excel will be launched in the interactive session as well, instead of a protected hidden user session with no real desktop. What's likely happening, is that the second user connecting over RDP is closing all other sessions when they log on, or locking all sessions as they log off.
here are security risks when you enable automatic logon or disable the screen saver because you enable other users to walk up to the computer and use the account that automatically logs on. If you configure the agent to run in this way, you must ensure the computer is physically protected; for example, located in a secure facility. If you use Remote Desktop to access the computer on which an agent is running with auto-logon, simply closing the Remote Desktop causes the computer to be locked and any UI tests that run on this agent may fail. To avoid this, use the tscon command to disconnect from Remote Desktop. For example:
%windir%\System32\tscon.exe 1 /dest:console
https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/agents?view=azure-devops#interactive-or-service
Another problem concerning excel automation on a server, is that existing Excel instances are re-used. This may cause the host excel to run under different credentials than the process doing the automation.
To run the agent interactively configure the serves to auto-logon (this utility encrypts the credentials used) and add run.cmd in the agent folder to the start-up executable list (either in the registry or a shortcut in the start menu). You can also make the agent executable (c:\windows\system32\cmd.exe /c path\to\agent\run.cmd) the default shell. There are quite a few docs on setting a custom shell.
You'll need to disable the screensaver and lockscreen for this session as well, which well require you to physically secure the server, otherwise anyone with access to the servers console will be able to access the running interactive session.
And you must unsure you always disconnect the remote desktop session without locking it (like above).
We finally identified that the problem only happened when using the RDP from a laptop having a touchscreen.
We then disabled the touchscreen using this documentation :
In the search box on the taskbar, type Device Manager, then select
Device Manager.
Select the arrow next to Human Interface Devices and
then select HID-compliant touch screen. (There may be more than one
listed.)
Select the Action tab at the top of the window.
Select Disable device or Enable device, and then confirm. If there's more
than one HID-compliant touchscreen device listed, perform steps 2–3
for that one too.
https://support.microsoft.com/en-us/help/4028019/windows-enable-and-disable-your-touchscreen-in-windows-10
And the script stopped crashing.
If someone want to post an answer to solve this problem without disabling touchscreen by tweaking the parameters in RDP or in the server we RDP to, i'd accept his answer as it's easier to change the parameter once than to ask people to disable their touchscreen when they rdp to our machine.
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'm working on a automated script for deploying sharepoint projects. I'm using a sandbox level webtemplate that must be applied when de site is created. I had a lot of troubles doing that because it seems like sharepoint caches the list of webtemplates and get-spwebtemplate doens't find the new added one. The way I made it work is this:
[system.reflection.assembly]::LoadWithPartialName("Microsoft.Sharepoint")
$site= new-Object Microsoft.SharePoint.SPSite($web_application_complete_url)
$site.OpenWeb().ApplyWebTemplate($web_template_name)
$site.Dispose()
As you can see, I'm using the .net sharepoint api instead of the cmdlets. This works sweet in PowerShell ISE but in the PowerShell console it throws an exception regarding a referenced DLL:
Exception calling "ApplyWebTemplate" with "1" argument(s): "Could not load file
or assembly 'XXX.SharePoint.Common, Version=1.0.0.0, Culture=neutral, PublicK
eyToken=534c125b45123456' or one of its dependencies. The system cannot find th
e file specified."
At C:\Build\SharePointBuild.p
s1:318 char:37
+ $site.OpenWeb().ApplyWebTemplate <<<< ($web_template_name)
+ CategoryInfo : NotSpecified: (:) [], ParentContainsErrorRecordE
xception
+ FullyQualifiedErrorId : DotNetMethodException
The assembly is perfectly registered in the GAC when installing the web template sandbox solution in the sitecollection.
Any ideas? thanks!
Is there any chance you are running 64-bit ISE and 32-bit PowerShell console (or vice-versa)? If it's not that then another difference is that ISE runs in COM STA mode whereas PowerShell Console runs in MTA by default. This would only matter if SharePoint uses COM under the covers (which I think it does). You could verify this by running PowerShell Console in STA mode like so:
C:\> Start-Process PowerShell -arg -sta
Assuming you're on PowerShell 2.0 for the Start-Process cmdlet.