Here's the trace from the failing slave:
Connecting to 192.168.0.5
Failed to connect to port 135 of 192.168.0.5. Is Windows firewall blocking this port? Or did you disable DCOM service?
ERROR: Message not found for errorCode: 0x8001FFFF
org.jinterop.dcom.common.JIException: Message not found for errorCode: 0x8001FFFF
at org.jinterop.dcom.core.JIComServer.call(JIComServer.java:876)
at org.jinterop.dcom.core.JIComServer.call(JIComServer.java:825)
at org.jinterop.dcom.core.JIComServer.addRef_ReleaseRef(JIComServer.java:909)
at org.jinterop.dcom.core.JISession.releaseRef(JISession.java:730)
at org.jinterop.dcom.core.JIComServer.createInstance(JIComServer.java:746)
at org.jvnet.hudson.wmi.WMI.connect(WMI.java:61)
at hudson.os.windows.ManagedWindowsServiceLauncher.launch(ManagedWindowsServiceLauncher.java:152)
at hudson.slaves.DelegatingComputerLauncher.launch(DelegatingComputerLauncher.java:56)
at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:199)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:314)
at java.util.concurrent.FutureTask.run(FutureTask.java:149)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:897)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:919)
at java.lang.Thread.run(Thread.java:736)
Caused by: java.net.SocketException: Network is unreachable
at sun.nio.ch.Net.connect(Native Method)
at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:519)
at java.nio.channels.SocketChannel.open(SocketChannel.java:157)
at org.jinterop.dcom.transport.JIComTransport.attach(JIComTransport.java:98)
at rpc.Stub.attach(Stub.java:104)
at org.jinterop.dcom.core.JIComServer.call(JIComServer.java:860)
... 13 more
I've already been through the suggestions at https://wiki.jenkins-ci.org/display/JENKINS/Windows+slaves+fail+to+start+via+DCOM, but no luck.
Using nmap on my jenkins machine, running as user jenkins, I can see that the ports are open on the slave. I can even telnet/netcat to it.
PORT STATE SERVICE
135/tcp open msrpc
139/tcp open netbios-ssn
445/tcp open microsoft-ds
3389/tcp open ms-term-serv
Sounds like it might be a bug in j-Interop, but can't confirm:
http://sourceforge.net/projects/j-interop/forums/forum/840678/topic/3732777
- duplicates
-
JENKINS-11000 Windows DCOM slave fails to connect
-
- Resolved
-
- is duplicated by
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
- is related to
-
-
- Resolved
-
[JENKINS-11002] Windows DCOM slave fails to connect
We need this feature very badly, As Everything related to Windows 7 (Resolution) worked perfectly and we were able to create template out of the same, so that we never face the issue. But for Windows 2008 R2 (64 bit) Server, Issue still exists. I will try and work on getting the exact root cause, if we cannot get it working as issue is with NTLMv2 Authentication. As we are moving towards VMWare vSphere Cloud & Lab management features of Jenkins, this becomes more and more important for dynamic deployment.
I am looking into this and will try assign it as well.
Issue still persists on Windows 2008 R2 server and was never resolved for the same. Only windows 7 (all version) works with the provided fixes
I've been banging my head on my desk all day with this issue. I'm experiencing the exact same issue trying to use Win2008R2 host as a build slave.
Already tried all the suggestions, tips and more, issue persists.
Have a Win7 build slave working fine, but can't get the dysfunctional win2008R2 host to cooperate.
Any info I can provide to help troubleshoot this issue?
Changing component to Windows Slaves, as the feature was extracted from core in 1.547.
Are any of you watchers experiencing this problem in Jenkins versions >1.560 or so? If so, please comment with the version of Jenkins + Windows Slaves plugin; the only Jenkins versions mentioned in this issue are three years obsolete...
@Daniel Beck - Running old Jenkins ver. 1.509.3 right now. Still working on getting free time to upgrade new servers to current version of Jenkins. Windows slave is Slave.jar version: 2.23.
Running Jenkins 2.73.1 i am able to reproduce. This is a 3 year old bug? wow. Would love to see this get resolved.
danielbeck yes. All DCOM logic belongs to Windows Slaves. Generally there are so many security restrictions around DCOM, I do not believe it can be reliably configured in enterprise instances.
My suggestion would be to use manually installed windows services as a workaround.
Won't be fixed. See JENKINS-67604 for the details of the deprecation of agents started by WMI calls using DCOM.
No response in two weeks to comment asking for updated and additional information, so resolving as Incomplete.