Can you describe the set up of your Windows 2008 server a bit more? Is it in a domain? A domain controller itself?

The error is "Access denied" when trying to access the registry from a remote machine. Can you think of anything that might have affected that?

We have the same problem. Here's some info about our setup:

• Windows Server 2008 R2 Standard x64
• Slave server is in domain (subdomain of the master Hudson's domain)
• Not a domain controller
• User defined in the slave configuration is Administrator of the slave's domain
• UAC is disabled (there was another error when it was enabled)
• Remote Registry service is on

• Windows Server 2008 R2 Enterprise x64
• Slave server is in same domain as the master Hudson, not a domain controller.
• UAC disabled.
• Remote Registry Service on

Note that I have it working fine on Windows 2008 Server Standard x64

We have the same problem. Configuration of environment:
Server:

• Hudson server running in Tomcat 6.0 on SLES 11 (amd64)
• Server is not in domain

Agent:

• Windows Server 2008 R2 Standard (x64)
• Server is in domain (using company domain controller)
• Local account with Administrators privileges
• Remote registry running
• Firewall disabled

I try connect remotely to Computer Management and Remote Registry. Both operation was successfully.

Seems to occur also on Windows 7 x64
cf JENKINS-4929

I have found out the problem, the Remote Registry user, in my case "LOCAL SERVICE", didn't have read access to the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winreg in the slave.

This problem happens because of a "strange" permission configuration on the slave side where the user running the Remote Registry service isn't able to read the registry entries which restrict the remote accessible registry paths, more specifically the children of
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winreg

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

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

'
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"

@Alexis Morelle: this worked for me to get rid off the winreg_CreateKey(JIWinRegStub.java:297) problem.
I am using a local Administrator account on the machine.
However, Jenkins then fails to find java:

Connecting to thehost.i.want
Checking if Java exists
'java' is not recognized as an internal or external command,
operable program or batch file.
No Java found. Downloading JDK
Installing JDK jdk-6u16-oth-JPR@CDS-CDS_Developer
Downloading JDK from http://download.oracle.com/otn/java/jdk/6u16-b01/jdk-6u16-windows-i586.exe
ERROR: Failed to prepare Java
java.net.ConnectException: Connection timed out
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:529)
at java.net.Socket.connect(Socket.java:478)
at java.net.Socket.<init>(Socket.java:375)
at java.net.Socket.<init>(Socket.java:249)
at org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.createSocket(DefaultProtocolSocketFactory.java:80)
at org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.createSocket(DefaultProtocolSocketFactory.java:122)
at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:707)
at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:387)
at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
at hudson.tools.JDKInstaller.locate(JDKInstaller.java:379)
at hudson.os.windows.ManagedWindowsServiceLauncher.launch(ManagedWindowsServiceLauncher.java:241)
at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:200)
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:662)
Copying jenkins-slave.xml
Copying slave.jar
Starting the service
—

JAVA_HOME is set for the local Administrator i am using, and also java is in the PATH environment variable for that user, but java.exe is somehow not found by Jenkins. Then downloading fails (proxy issue, oracle login policy ?) and then the service never starts.
This might be another issue altogether since i upgraded to 1.463 recently too.

After doing all this, even if you get the error Access denied.
Open the command prompt as administrator.
C:\>cd jenkins

C:\Jenkins>jenkins-slave.exe install

C:\Jenkins>

Here's the error on my setup. Thanks

• Jenkins Master installed on Ubuntu 14.04
• Jenkins Slave installed on Windows 7 32 bit

Windows Slave Setup

• Launch Method: Let jenkins control this windows slave as a windows service
• Administrator username
• Password
• Host: IP Adress
  *Run Service as: Use Administrator account given above

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: Message not found for errorCode: 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:59)
at hudson.os.windows.ManagedWindowsServiceLauncher.launch(ManagedWindowsServiceLauncher.java:206)
at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:261)
at jenkins.util.ContextResettingExecutorService$2.call(ContextResettingExecutorService.java:46)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
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

"Access denied" is an expected behavior if Jenkins runs without elevated permissions or if it has no proper permissions on the target machine. I am not sure how it can be fixed on the Jenkins side

The WBEM Scripting Locator is since 2012 only accessible by the TrustedInstaller service. An Administrator can't access it. So running Jenkins with elevated permissions is not going to help. I don't see how the DCOM-based approach can work out-of-the-box without resorting to above mentioned hacks.

Encountering same thing.  no upvotes so adding support of others comments.

paulhendley with Windows Server 2019 and with the most recent Windows 10 service packs Microsoft now provides the Microsoft OpenSSH Server. If you're using new enough operating systems, it is much simpler to manage the Windows agents with ssh than to fight with the DCOM approach used by the windows slaves plugin.

Refer to the windows section of the ssh-slaves plugin for more information.

Won't be fixed. See JENKINS-67604 for the details of the deprecation of agents started by WMI calls using DCOM.