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
Marc Robinson
added a comment - Started seeing this as well on Jenkins 1.430 after adding Windows 2008 slaves. Master: RHEL 5 Slave: Windows server 2008 32bit SP 1
Marc Robinson
added a comment - Started seeing this as well on Jenkins 1.430 after adding Windows 2008 slaves. Master: RHEL 5 Slave: Windows server 2008 32bit SP 1
Zachary Young
added a comment - I am seeing this as well: From Jenkins 1.423 on Server 2008 to Server 2008. From the Jenkins master, I was able to go through regedit and make a remote connection to the would be slave's registry.
Zachary Young
added a comment - I am seeing this as well: From Jenkins 1.423 on Server 2008 to Server 2008. From the Jenkins master, I was able to go through regedit and make a remote connection to the would be slave's registry. 
Amar chandran
added a comment - I'm getting this error as well. Using Jenkins 1.436 ON Win2008R2SP1.
Amar chandran
added a comment - I'm getting this error as well. Using Jenkins 1.436 ON Win2008R2SP1. [bug report removed]
False alarm - my problem was not caused by this bug.
Doug Konrad
added a comment - - edited [bug report removed]
False alarm - my problem was not caused by this bug. Please resolve this, as all organizations are moving to windows 2008 R2 or windows 2012
pancake
added a comment - jeebitesh, we've been struggling Windows DCOM slaves for years. We had to examine plugin source code and make a few very non-obvious config changes to make it work on Windows 2012. Sometimes it just stops working for no reason, sometimes new plugin version ruins everything. From my experience I conclude that Jenkins dev team doesn't really care about Windows users, e.g. this obvious bug has never been fixed, so we had to invent a workaround: JENKINS-9528. So, what I advise is to rely on Jenkins plugins as little as possible. E.g. we've setup a scheduled task to run JNLP slave agent on our win slaves - this proved to cause much less pain than the DCOM slave plugin.
pancake
added a comment - jeebitesh , we've been struggling Windows DCOM slaves for years. We had to examine plugin source code and make a few very non-obvious config changes to make it work on Windows 2012. Sometimes it just stops working for no reason, sometimes new plugin version ruins everything. From my experience I conclude that Jenkins dev team doesn't really care about Windows users, e.g. this obvious bug has never been fixed, so we had to invent a workaround: JENKINS-9528 . So, what I advise is to rely on Jenkins plugins as little as possible. E.g. we've setup a scheduled task to run JNLP slave agent on our win slaves - this proved to cause much less pain than the DCOM slave plugin. Is this still an issue on recent Jenkins versions?
Do the solutions posted in the comments to JENKINS-4929 help?
No response in two weeks to comment asking for updated and additional information, so resolving as Incomplete.
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.
I'm seeing the same from Jenkins running on Windows2008 for master. The target slave is a Win2008R2SP1 machine. Firewall is off, credentials are local administrator. I ran enable-psremoting and rebooted as well.