Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-4929

windows 7 x86_64 slave fails to launch via DCOM

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Blocker
    • Resolution: Incomplete
    • Component/s: remoting
    • Labels:
      None
    • Environment:
      Platform: PC, OS: Windows 7
    • Similar Issues:

      Description

      This may not be a bug as I don't have another windows 7 box to test with, but it
      appears as though launching Windows 7 slaves via DCOM fails (this master can
      launch XP slaves via DCOM without incident). The slave has no firewall, the
      security policy for local accounts is set to 'classic', and the user is a member
      of the Administrators local group.

      Stack trace follows:

      Connecting to bursar
      Access is denied. See
      http://wiki.jenkins-ci.org/display/JENKINS/Windows+slaves+fail+to+start+via+DCOM
      for more information about how to resolve this.
      org.jinterop.dcom.common.JIException: Access is denied, please check whether the
      [domain-username-password] are correct. Also, if not already done please check
      the GETTING STARTED and FAQ sections in readme.htm. They provide information on
      how to correctly configure the Windows machine for DCOM access, so as to avoid
      such exceptions. [0x00000005]
      at org.jinterop.dcom.core.JIComServer.init(JIComServer.java:542)
      at org.jinterop.dcom.core.JIComServer.initialise(JIComServer.java:458)
      at org.jinterop.dcom.core.JIComServer.<init>(JIComServer.java:427)
      at org.jvnet.hudson.wmi.WMI.connect(WMI.java:41)
      at
      hudson.os.windows.ManagedWindowsServiceLauncher.launch(ManagedWindowsServiceLauncher.java:107)
      at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:178)
      at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
      at java.util.concurrent.FutureTask.run(FutureTask.java:166)
      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
      at java.lang.Thread.run(Thread.java:636)
      Caused by: rpc.FaultException: Received fault. (unknown)
      at rpc.ConnectionOrientedEndpoint.call(ConnectionOrientedEndpoint.java:142)
      at rpc.Stub.call(Stub.java:112)
      at org.jinterop.dcom.core.JIComServer.init(JIComServer.java:538)
      ... 10 more

        Attachments

          Issue Links

            Activity

            Hide
            orrc Christopher Orr added a comment -

            Possibly a duplicate of JENKINS-4859?

            Show
            orrc Christopher Orr added a comment - Possibly a duplicate of JENKINS-4859 ?
            Hide
            daav daav added a comment -

            Seems to be the same.
            Here is the stack trace I get on Windows 7 64, which is the same trace than JENKINS-4859

            ERROR: Access is denied. See http://wiki.jenkins-ci.org/display/JENKINS/Windows+slaves+fail+to+start+via+DCOM for more information about how to resolve this.
            org.jinterop.dcom.common.JIException: Access is denied, please check whether the [domain-username-password] are correct. Also, if not already done please check the GETTING STARTED and FAQ sections in readme.htm. They provide information on how to correctly configure the Windows machine for DCOM access, so as to avoid such exceptions. [0x00000005]
            at org.jinterop.winreg.smb.JIWinRegStub.winreg_CreateKey(JIWinRegStub.java:297)
            at org.jinterop.dcom.core.JIComServer.initialise(JIComServer.java:480)
            at org.jinterop.dcom.core.JIComServer.<init>(JIComServer.java:427)
            at org.jvnet.hudson.wmi.WMI.connect(WMI.java:41)
            at hudson.os.windows.ManagedWindowsServiceLauncher.launch(ManagedWindowsServiceLauncher.java:137)
            at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:183)
            at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
            at java.util.concurrent.FutureTask.run(FutureTask.java:138)
            at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
            at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
            at java.lang.Thread.run(Thread.java:619)
            Caused by: org.jinterop.dcom.common.JIRuntimeException: Access is denied, please check whether the [domain-username-password] are correct. Also, if not already done please check the GETTING STARTED and FAQ sections in readme.htm. They provide information on how to correctly configure the Windows machine for DCOM access, so as to avoid such exceptions. [0x00000005]
            at org.jinterop.winreg.IJIWinReg$createKey.read(IJIWinReg.java:459)
            at ndr.NdrObject.decode(NdrObject.java:19)
            at rpc.ConnectionOrientedEndpoint.call(ConnectionOrientedEndpoint.java:138)
            at rpc.Stub.call(Stub.java:112)
            at org.jinterop.winreg.smb.JIWinRegStub.winreg_CreateKey(JIWinRegStub.java:291)
            ... 10 more

            Show
            daav daav added a comment - Seems to be the same. Here is the stack trace I get on Windows 7 64, which is the same trace than JENKINS-4859 ERROR: Access is denied. See http://wiki.jenkins-ci.org/display/JENKINS/Windows+slaves+fail+to+start+via+DCOM for more information about how to resolve this. org.jinterop.dcom.common.JIException: Access is denied, please check whether the [domain-username-password] are correct. Also, if not already done please check the GETTING STARTED and FAQ sections in readme.htm. They provide information on how to correctly configure the Windows machine for DCOM access, so as to avoid such exceptions. [0x00000005] at org.jinterop.winreg.smb.JIWinRegStub.winreg_CreateKey(JIWinRegStub.java:297) at org.jinterop.dcom.core.JIComServer.initialise(JIComServer.java:480) at org.jinterop.dcom.core.JIComServer.<init>(JIComServer.java:427) at org.jvnet.hudson.wmi.WMI.connect(WMI.java:41) at hudson.os.windows.ManagedWindowsServiceLauncher.launch(ManagedWindowsServiceLauncher.java:137) at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:183) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Caused by: org.jinterop.dcom.common.JIRuntimeException: Access is denied, please check whether the [domain-username-password] are correct. Also, if not already done please check the GETTING STARTED and FAQ sections in readme.htm. They provide information on how to correctly configure the Windows machine for DCOM access, so as to avoid such exceptions. [0x00000005] at org.jinterop.winreg.IJIWinReg$createKey.read(IJIWinReg.java:459) at ndr.NdrObject.decode(NdrObject.java:19) at rpc.ConnectionOrientedEndpoint.call(ConnectionOrientedEndpoint.java:138) at rpc.Stub.call(Stub.java:112) at org.jinterop.winreg.smb.JIWinRegStub.winreg_CreateKey(JIWinRegStub.java:291) ... 10 more
            Hide
            sayres sayres added a comment -

            A duplicate of JENKINS-6385 except for 64 bit machines perhaps? I posted a fix that seems to be working for me on that issue since my Windows 7 box is 32 bit.

            Show
            sayres sayres added a comment - A duplicate of JENKINS-6385 except for 64 bit machines perhaps? I posted a fix that seems to be working for me on that issue since my Windows 7 box is 32 bit.
            Hide
            daav daav added a comment - - edited

            Made the try for the fix suggested in JENKINS-6385 (set user name to "user.machinename"), but without success:

            ERROR: Access is denied. See http://wiki.jenkins-ci.org/display/JENKINS/Windows+slaves+fail+to+start+via+DCOM for more information about how to resolve this.
            org.jinterop.dcom.common.JIException: Access is denied, please check whether the [domain-username-password] are correct. Also, if not already done please check the GETTING STARTED and FAQ sections in readme.htm. They provide information on how to correctly configure the Windows machine for DCOM access, so as to avoid such exceptions. [0x00000005]
            at org.jinterop.dcom.core.JIComServer.init(JIComServer.java:542)
            at org.jinterop.dcom.core.JIComServer.initialise(JIComServer.java:458)
            at org.jinterop.dcom.core.JIComServer.<init>(JIComServer.java:427)
            at org.jvnet.hudson.wmi.WMI.connect(WMI.java:41)
            at hudson.os.windows.ManagedWindowsServiceLauncher.launch(ManagedWindowsServiceLauncher.java:137)
            at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:183)
            at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
            at java.util.concurrent.FutureTask.run(FutureTask.java:138)
            at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
            at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
            at java.lang.Thread.run(Thread.java:619)
            Caused by: rpc.FaultException: Received fault. (unknown)
            at rpc.ConnectionOrientedEndpoint.call(ConnectionOrientedEndpoint.java:142)
            at rpc.Stub.call(Stub.java:112)
            at org.jinterop.dcom.core.JIComServer.init(JIComServer.java:538)
            ... 10 more

            Show
            daav daav added a comment - - edited Made the try for the fix suggested in JENKINS-6385 (set user name to "user.machinename"), but without success: ERROR: Access is denied. See http://wiki.jenkins-ci.org/display/JENKINS/Windows+slaves+fail+to+start+via+DCOM for more information about how to resolve this. org.jinterop.dcom.common.JIException: Access is denied, please check whether the [domain-username-password] are correct. Also, if not already done please check the GETTING STARTED and FAQ sections in readme.htm. They provide information on how to correctly configure the Windows machine for DCOM access, so as to avoid such exceptions. [0x00000005] at org.jinterop.dcom.core.JIComServer.init(JIComServer.java:542) at org.jinterop.dcom.core.JIComServer.initialise(JIComServer.java:458) at org.jinterop.dcom.core.JIComServer.<init>(JIComServer.java:427) at org.jvnet.hudson.wmi.WMI.connect(WMI.java:41) at hudson.os.windows.ManagedWindowsServiceLauncher.launch(ManagedWindowsServiceLauncher.java:137) at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:183) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Caused by: rpc.FaultException: Received fault. (unknown) at rpc.ConnectionOrientedEndpoint.call(ConnectionOrientedEndpoint.java:142) at rpc.Stub.call(Stub.java:112) at org.jinterop.dcom.core.JIComServer.init(JIComServer.java:538) ... 10 more
            Hide
            sayres sayres added a comment -

            One point of note is that when I use "user.machinename" it still sometimes throws the error but then manages to connect after 10-15 seconds. Will take a closer look at the machine to see what else I could have changed to fix the issue.

            Show
            sayres sayres added a comment - One point of note is that when I use "user.machinename" it still sometimes throws the error but then manages to connect after 10-15 seconds. Will take a closer look at the machine to see what else I could have changed to fix the issue.
            Hide
            sayres sayres added a comment -

            I found a high-risk workaround from this j-interop forum post: http://sourceforge.net/projects/j-interop/forums/forum/840678/topic/3398900
            It's high-risk because it requires you to modify a Windows Resource Protection registry key, so perform the following steps at your own risk with caution.

            The workaround was provided by csturtz in the j-interop forum post:

            I ran into this same issue on Windows 2008 R2. The application I have accesses process information from the remote host. It uses auto registration set to true. It was failing for me when JInterop tried to modify the registry because the items it needed to modify had an owner of Trusted Installer and nothing else could touch them (not even if you logged in as an administrator and tried modifying them yourself). I did find a work-around that worked for me. I've heard it doesn't work for everyone, but it might be worth a shot.
            1. Login to the target remote host as an Administrator.
            2. Run the program Regedit
            3. If you are asked to allow the Regedit program to make changes to the computer, click 'Yes'
            4. Navigate to the Registry item HKEY_CLASSES_ROOT\CLSID{YOUR CLSID HERE}
            5. Right click on this item and select 'Permissions'
            6. Click 'Advanced'
            7. Select the 'Owner' tab
            8. In the 'Change Owner to...' box, highlight the account you are currently logged in as.
            9. Click 'Ok'
            10. Click 'Ok'
            11. Right click the registry item again and select 'Permissions'
            12. Highlight the 'Administrators' group 13. Give 'Full Control' permissions to this group by checking the 'Allow' box
            14. Click 'Ok'

            The registry key that needs to be modified is found from this line of the stack trace at org.jvnet.hudson.wmi.WMI.connect(WMI.java:41) i.e. *

            {76A64158-CB41-11D1-8B02-00600806D9B6}

            *

            In my case, the Windows 7 slave machine wasn't on a domain so for the Administrator username I specified SLAVE_MACHINE_NAME\Administrator. After a restart of the slave machine, the master installed and started the Hudson slave service with a new service name 'Hudson Slave at C:\hudson' (it previously was named just 'Hudson Slave'). The master has been able to successfully start the stopped slave service multiple times now without error. I hope this helps anyone else who was pulling out their hair looking for a fix.

            Show
            sayres sayres added a comment - I found a high-risk workaround from this j-interop forum post: http://sourceforge.net/projects/j-interop/forums/forum/840678/topic/3398900 It's high-risk because it requires you to modify a Windows Resource Protection registry key, so perform the following steps at your own risk with caution. The workaround was provided by csturtz in the j-interop forum post: I ran into this same issue on Windows 2008 R2. The application I have accesses process information from the remote host. It uses auto registration set to true. It was failing for me when JInterop tried to modify the registry because the items it needed to modify had an owner of Trusted Installer and nothing else could touch them (not even if you logged in as an administrator and tried modifying them yourself). I did find a work-around that worked for me. I've heard it doesn't work for everyone, but it might be worth a shot. 1. Login to the target remote host as an Administrator. 2. Run the program Regedit 3. If you are asked to allow the Regedit program to make changes to the computer, click 'Yes' 4. Navigate to the Registry item HKEY_CLASSES_ROOT\CLSID{YOUR CLSID HERE} 5. Right click on this item and select 'Permissions' 6. Click 'Advanced' 7. Select the 'Owner' tab 8. In the 'Change Owner to...' box, highlight the account you are currently logged in as. 9. Click 'Ok' 10. Click 'Ok' 11. Right click the registry item again and select 'Permissions' 12. Highlight the 'Administrators' group 13. Give 'Full Control' permissions to this group by checking the 'Allow' box 14. Click 'Ok' The registry key that needs to be modified is found from this line of the stack trace at org.jvnet.hudson.wmi.WMI.connect(WMI.java:41) i.e. * {76A64158-CB41-11D1-8B02-00600806D9B6} * In my case, the Windows 7 slave machine wasn't on a domain so for the Administrator username I specified SLAVE_MACHINE_NAME\Administrator. After a restart of the slave machine, the master installed and started the Hudson slave service with a new service name 'Hudson Slave at C:\hudson' (it previously was named just 'Hudson Slave'). The master has been able to successfully start the stopped slave service multiple times now without error. I hope this helps anyone else who was pulling out their hair looking for a fix.
            Hide
            daav daav added a comment -

            Great tip.
            Works for me!

            Show
            daav daav added a comment - Great tip. Works for me!
            Hide
            sauravsengupta sauravsengupta added a comment -

            Another tip to add to this. This may be obvious to others, but it wasn't to me, so maybe this will help someone else who stumbles onto this.

            I made the registry change mentioned above, and got past the 'access denied' exception. However, it still didn't work. Turns out, the slave machine tries to run javaw.exe. On Windows 7 64-bit, this is installed in C:\Windows\SysWOW64. However, that directory wasn't in my path. So the Hudson slave wouldn't launch, and the application logs would show 'could not find the specified file' error messages. After adding this directory to the PATH environment variable and restarting the PC, I was finally able to connect.

            Show
            sauravsengupta sauravsengupta added a comment - Another tip to add to this. This may be obvious to others, but it wasn't to me, so maybe this will help someone else who stumbles onto this. I made the registry change mentioned above, and got past the 'access denied' exception. However, it still didn't work. Turns out, the slave machine tries to run javaw.exe. On Windows 7 64-bit, this is installed in C:\Windows\SysWOW64. However, that directory wasn't in my path. So the Hudson slave wouldn't launch, and the application logs would show 'could not find the specified file' error messages. After adding this directory to the PATH environment variable and restarting the PC, I was finally able to connect.
            Hide
            pablaasmo Per Arnold Blaasmo added a comment -

            I tested this with Jenkins 1.397 SNAPSHOT and still has this problem.
            According to Changelog for 1.387 "* Install as a service" now supports Vista and Windows 7." it should have been resolved, but apparently not for 64-bit.

            My Java is in the C:\windows\system32\java.exe so I do not have the PATH issue.
            I solved it manually the following way:
            1. I copied the jenkins-slave.exe, jenkins-slave.xml and slave.jar to the workspace C:\hudson on the slave machine.
            2. Edit the XML file to replace @ID@ @APP@ and @ARGS@ with the correct values for this slave.
            3. Open a cmd window in administrator mode and run 'jenkins-slave.exe install'
            4. Start administer services and choose properties for the 'Jenkins Slave' service.
            5. Choose to add a logon to the service using a local user (same user the build master uses to log on with) with administer group membership.
            6. start the service
            7. configure the build on the build master to use windows service to connect to slave.

            This works for me

            I do not know if all these steps are necessary, but...

            I would be nice if someone with knowledge on this on Windows 7 64bit could find a way to start a service remote from Hudson/Jenkins.

            Show
            pablaasmo Per Arnold Blaasmo added a comment - I tested this with Jenkins 1.397 SNAPSHOT and still has this problem. According to Changelog for 1.387 "* Install as a service" now supports Vista and Windows 7." it should have been resolved, but apparently not for 64-bit. My Java is in the C:\windows\system32\java.exe so I do not have the PATH issue. I solved it manually the following way: 1. I copied the jenkins-slave.exe, jenkins-slave.xml and slave.jar to the workspace C:\hudson on the slave machine. 2. Edit the XML file to replace @ID@ @APP@ and @ARGS@ with the correct values for this slave. 3. Open a cmd window in administrator mode and run 'jenkins-slave.exe install' 4. Start administer services and choose properties for the 'Jenkins Slave' service. 5. Choose to add a logon to the service using a local user (same user the build master uses to log on with) with administer group membership. 6. start the service 7. configure the build on the build master to use windows service to connect to slave. This works for me I do not know if all these steps are necessary, but... I would be nice if someone with knowledge on this on Windows 7 64bit could find a way to start a service remote from Hudson/Jenkins.
            Hide
            kora Ralf Konusch added a comment -

            I found a way / workaround to launch a Windows 64 Bit slave from a windows master:

            Use JNPL to launch a 64 bit windows slave.

            On the jenkins master platform:

            • Launch a jenkins instance
            • jenkins- web UI:
            • manage nodes - new node
            • Configure a node to the slave machine to launch it as a JNPL slave agent
            • save the configuration

            On the jenkins slave platform:

            • launch a jenkins instance
            • jenkins- web UI:
            • manage nodes - new node
            • Configure a node on this machine (take the physical IP number of the slave platform) to launch it as a JNPL slave agent
            • Remember the home directory of the slave (e.g. ....\.jenkins\slave)
            • launch the slave agent
            • in the slave agent window choose "File" > "Install as Windows Service" from the menu
            • Confirm your intention to install as a service.
            • Once the installation succeeds, you'll be asked if you'd like to stop the current slave agent and immediately start a slave agent.
            • When you click "OK", the slave agent window will terminate.
            • stop the jenkins instance now.
            • Open the windows services using services.msc in the command shell
            • the "Jenkins Slave" now will be listed as a service
            • open it to check it's general properties to start the service automatically
            • In file browser browse to the directory of the slave (e.g. ....\.jenkins\slave)
            • edit the file jenkins-slave.xml
            • search for "localmachine" and replace it to the physical IP- number of the jenkins master platform
            • save the jenkins-slave.xml
            • restart the "Jenkins Slave" service
            • now the slave platform will automatically start the jenkins slave connected via JNPL agent to the master platform
            Show
            kora Ralf Konusch added a comment - I found a way / workaround to launch a Windows 64 Bit slave from a windows master: Use JNPL to launch a 64 bit windows slave. On the jenkins master platform: Launch a jenkins instance jenkins- web UI: manage nodes - new node Configure a node to the slave machine to launch it as a JNPL slave agent save the configuration On the jenkins slave platform: launch a jenkins instance jenkins- web UI: manage nodes - new node Configure a node on this machine (take the physical IP number of the slave platform) to launch it as a JNPL slave agent Remember the home directory of the slave (e.g. ....\.jenkins\slave) launch the slave agent in the slave agent window choose "File" > "Install as Windows Service" from the menu Confirm your intention to install as a service. Once the installation succeeds, you'll be asked if you'd like to stop the current slave agent and immediately start a slave agent. When you click "OK", the slave agent window will terminate. stop the jenkins instance now. Open the windows services using services.msc in the command shell the "Jenkins Slave" now will be listed as a service open it to check it's general properties to start the service automatically In file browser browse to the directory of the slave (e.g. ....\.jenkins\slave) edit the file jenkins-slave.xml search for "localmachine" and replace it to the physical IP- number of the jenkins master platform save the jenkins-slave.xml restart the "Jenkins Slave" service now the slave platform will automatically start the jenkins slave connected via JNPL agent to the master platform
            Hide
            evilchili evilchili added a comment - - edited

            If you have the Remote Registry service running, try connecting to the registry on your slave via regedit on another machine. If you get a similar error ("Access is denied"), run powershell as an administrator on the slave, and execute Enable-PSRemoting.

            This should allow remote access to the registry; you may still require fixing permissions on the registry key as mentioned elsewhere.

            Show
            evilchili evilchili added a comment - - edited If you have the Remote Registry service running, try connecting to the registry on your slave via regedit on another machine. If you get a similar error ("Access is denied"), run powershell as an administrator on the slave, and execute Enable-PSRemoting. This should allow remote access to the registry; you may still require fixing permissions on the registry key as mentioned elsewhere.
            Hide
            almorelle Alexis Morelle added a comment -

            There's a workaround less complicated thanks to Florian Vogler from Hudson-ci wiki.
            It can be applied to Microsoft Windows 7 too.

            "This is caused by the TrustedInstaller concept of windows.

            Solution I found so far:

            Hudson requires full access to WBEM Scripting Locator (HKEY_CLASSES_ROOT\CLSID

            {76A64158-CB41-11D1-8B02-00600806D9B6}). Default for administrators group is just read.
            Change permissions for administrators group to "Full Control".

            Launch 'regedit.exe' as 'Administrator'
            Find the following registry key: 'HKEY_CLASSES_ROOT\CLSID{76A64158-CB41-11D1-8B02-00600806D9B6}

            '
            Right click and select 'Permissions'
            Change owner to administrators group.
            Change permissions for administrators group. Grant Full Control.
            Change owner back to TrustedInstaller (user is "NT Service\TrustedInstaller")
            Restart Remote Registry Service"

            Show
            almorelle Alexis Morelle added a comment - There's a workaround less complicated thanks to Florian Vogler from Hudson-ci wiki. It can be applied to Microsoft Windows 7 too. "This is caused by the TrustedInstaller concept of windows. Solution I found so far: Hudson requires full access to WBEM Scripting Locator (HKEY_CLASSES_ROOT\CLSID {76A64158-CB41-11D1-8B02-00600806D9B6}). Default for administrators group is just read. Change permissions for administrators group to "Full Control". Launch 'regedit.exe' as 'Administrator' Find the following registry key: 'HKEY_CLASSES_ROOT\CLSID{76A64158-CB41-11D1-8B02-00600806D9B6} ' Right click and select 'Permissions' Change owner to administrators group. Change permissions for administrators group. Grant Full Control. Change owner back to TrustedInstaller (user is "NT Service\TrustedInstaller") Restart Remote Registry Service"
            Hide
            danielbeck Daniel Beck added a comment -

            It looks like there's no recent issues with this type of slave launch that isn't covered by the wiki page (the WBEM one was mentioned at least twice in the comments here already), therefore I'm resolving as Incomplete.

            If you encounter a similar issue on a recent Jenkins version and tried everything on the linked wiki page with no success, please file a new issue and add a link back to this one.

            Show
            danielbeck Daniel Beck added a comment - It looks like there's no recent issues with this type of slave launch that isn't covered by the wiki page (the WBEM one was mentioned at least twice in the comments here already), therefore I'm resolving as Incomplete. If you encounter a similar issue on a recent Jenkins version and tried everything on the linked wiki page with no success, please file a new issue and add a link back to this one.

              People

              • Assignee:
                Unassigned
                Reporter:
                evilchili evilchili
              • Votes:
                18 Vote for this issue
                Watchers:
                18 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: