different behaviour of azure devops agents on hosted vm when different computer access the vm - excel

Question

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 :

Answer 1

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).

Answer 2

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.