Powershell script instantiating COM class failed in Jenkins pipeline

Community
,
1

Hello all,

I have a jenkins node running on a windows server 2019. The Jenkins service runs with privileges of a windows service user which has no admin rights on that server.

When I’ve been logged in with this service user on the windows server and start the powershell script in the Powershell ISE environment, this works fine, but when this ps1 script is called within a Jenkins pipeline it throws an error “access denied”.

The ps1 script instantiates a COM class like:

# Create the EA object

#$ea = New-Object -ComObject “EA.Repository” -Strict

The error is as follows

powershell.exe : New-Object : Retrieving the COM class factory for component with CLSID {67F4E0FA-46A7-4255-B084-69A9433D08C3} failed At C:\KBData\Jenkins_Home\workspace\PureVariants EA Model Transformation@tmp\durable-f80e2bfd\powershellWrapper.ps1:3 char:1 + & powershell -NoProfile -NonInteractive -ExecutionPolicy Bypass -Comm … + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : NotSpecified: (New-Object : Re…3D08C3} failed :String) , RemoteException + FullyQualifiedErrorId : NativeCommandError due to the following error: 80070005 Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)). At C:\KBData\Sandbox\EA-models\project_transfer_cvsm.ps1:32 char:7 + $ea = New-Object -ComObject “EA.Repository” -Strict + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : NotSpecified: (:slight_smile: [New-Object], UnauthorizedAccessException + FullyQualifiedErrorId : System.UnauthorizedAccessException,Microsoft.PowerShell.Commands.NewObjectCommand

Has someone an idea why this COM class can not be instantiated in jenkins node context despite the Jenkins service runs with privileges of the service user?

Best regards

Wolfgang

2

Hello and welcome to this community, @WolfgangS. :waving_hand:

It looks like the error comes from how Windows handles COM objects when Jenkins is running as a service. In a service context, the process is in Session 0 (non-interactive), which often prevents COM objects from starting properly, especially those that expect a desktop session or elevated rights.

A few things you might try:

  • Interactive desktop access
    Some COM objects (for example, EA.Repository) don’t behave well in Session 0. If that’s the case, you may have better luck running the Jenkins agent as a regular process in an interactive session instead of as a Windows service.
  • Permissions via DCOMCNFG
    It may help to grant your Jenkins service account explicit “Launch and Activation” permissions for the COM class. You can configure this through dcomcnfg.
  • UAC / policy considerations
    On some setups, UAC or local security policies can block non-admin accounts from creating COM objects. Checking the local policy settings might be worth a shot.

So in practice, two common paths forward are:

  1. Adjust the DCOM permissions, so the service account can create the COM object.
  2. Run the Jenkins agent interactively (instead of as a service) under the account that needs COM access.

This behavior is fairly typical on Windows when trying to automate COM from a background service, so it may take a bit of experimentation depending on the COM component you’re working with.

Option 1: Grant DCOM permissions to the Jenkins service account

  1. Open Component Services
  • Press Win + R, type dcomcnfg, and hit Enter.
  • This opens Component Services.
  1. Navigate to the COM class
  • In the left tree:
    Component Services → Computers → My Computer → DCOM Config
  • Find the COM object you’re working with (e.g., EA.Repository).
  1. Adjust security settings
  • Right-click the COM object → Properties.
  • Go to the Security tab.
  1. Launch and Activation Permissions
  • Under Launch and Activation Permissions, click Edit.
  • Add the Jenkins service account (the one Jenkins is running under).
  • Grant it at least:
    • Local Launch
    • Local Activation
  • If the agent runs remotely, you might also need Remote Launch/Activation.
  1. Save and restart Jenkins
  • Click OK to save settings.
  • Restart the Jenkins service, so the new permissions take effect.

Option 2: Run Jenkins agent interactively

Sometimes the easiest fix is to avoid Session 0 entirely.

  1. Stop the service
  • Open Services.msc.
  • Find Jenkins Agent (or the Windows service you installed for Jenkins).
  • Right-click → Stop.
  1. Launch as a process instead of a service
  • Open a command prompt as the Jenkins user (e.g., with runas /user:jenkins cmd).
  • Run the agent JAR directly:
java -jar agent.jar -jnlpUrl <your-jenkins-url>/computer/<agent-name>/jenkins-agent.jnlp -secret <secret> -workDir "<path>"
  • This ensures the agent runs in the user’s interactive session, where COM access typically works fine.
  1. Make it persistent
  • You could wrap this in a scheduled task that runs “at logon” for the Jenkins user.
  • That way, whenever the machine reboots, the agent starts automatically in an interactive session.

Summary

  • If you want to keep Jenkins as a service: Use dcomcnfg to explicitly grant your service account permissions on the COM class.
  • If the COM object simply doesn’t work in Session 0: Run the Jenkins agent interactively (scheduled task at logon is a good compromise).

Here’s a ready-to-use Scheduled Task XML that should launch the Jenkins agent in an interactive session at user logon. You could import this into Task Scheduler instead of building it by hand.

1. Save as jenkins-agent.xml

<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.3" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
  <RegistrationInfo>
    <Author>Jenkins</Author>
    <Description>Run Jenkins agent interactively at logon</Description>
  </RegistrationInfo>
  <Triggers>
    <LogonTrigger>
      <Enabled>true</Enabled>
    </LogonTrigger>
  </Triggers>
  <Principals>
    <!-- Replace 'JENKINSUSER' with the actual account -->
    <Principal id="Author">
      <UserId>DOMAIN\JENKINSUSER</UserId>
      <LogonType>InteractiveToken</LogonType>
      <RunLevel>LeastPrivilege</RunLevel>
    </Principal>
  </Principals>
  <Settings>
    <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
    <DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
    <StopIfGoingOnBatteries>false</StopIfGoingOnBatteries>
    <AllowHardTerminate>true</AllowHardTerminate>
    <StartWhenAvailable>true</StartWhenAvailable>
    <RunOnlyIfNetworkAvailable>true</RunOnlyIfNetworkAvailable>
    <IdleSettings>
      <StopOnIdleEnd>false</StopOnIdleEnd>
      <RestartOnIdle>false</RestartOnIdle>
    </IdleSettings>
    <Enabled>true</Enabled>
    <Hidden>false</Hidden>
    <RunOnlyIfIdle>false</RunOnlyIfIdle>
    <DisallowStartOnRemoteAppSession>false</DisallowStartOnRemoteAppSession>
    <UseUnifiedSchedulingEngine>true</UseUnifiedSchedulingEngine>
    <WakeToRun>true</WakeToRun>
  </Settings>
  <Actions Context="Author">
    <Exec>
      <Command>java</Command>
      <Arguments>-jar "C:\jenkins\agent.jar" -jnlpUrl https://YOUR_JENKINS_URL/computer/AGENT_NAME/jenkins-agent.jnlp -secret YOUR_SECRET -workDir "C:\jenkins"</Arguments>
      <WorkingDirectory>C:\jenkins</WorkingDirectory>
    </Exec>
  </Actions>
</Task>

2. Import into Task Scheduler

schtasks /Create /XML jenkins-agent.xml /TN "JenkinsAgent"

3. Adjust placeholders

  • Replace DOMAIN\JENKINSUSER with the actual Jenkins user account.
  • Update paths:
    • C:\jenkins\agent.jar → where you keep the agent JAR.
    • https://YOUR_JENKINS_URL/... → your Jenkins controller URL.
    • AGENT_NAME and YOUR_SECRET → values from the Jenkins agent config page.

Result

Whenever the Jenkins user logs in, Windows should start the Jenkins agent in their interactive desktop session. That way, COM objects like EA.Repository that require interactive access should initialize correctly.

3

All of this does not work for me! My query to the EA SparxSystems Support results in the answer that EA UI doesn’t support DCOM. Assuming that the UI and even a logged in user is recommended when instantiating this COM class.