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
            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: