We recently moved from a Windows 2003 server to Windows 2008 R2 server and now I see that all my psexec jobs fail.
thsi is how they are coded to run:
c:\shell\psexec.exe \NTDB2UT02 -u conseco\plat -i cmd.exe
I then get prompted for a password and as soon as I enter the password I get the error message below
PsExec v1.31 - execute processes remotely
Copyright (C) 2001-2002 Mark Russinovich
www.sysinternals.com
Password:
Could not start PsExec service on NTDB2UT02:
The system cannot find the file specified.
So I went back to the Windows 2003 server that we were using earlier and I know it worked there because I have proof that it ran, and now I get the same message from the old Windows 2003 server too.
I read on a few posts that I could use the cmdkey to add a cached credential and I even tried doing that on both servers, but it didnt help at all.
I am going to try using a newer version of psexec, but I doubt that this will change anything at all.
Any tips or if anyone has successfully figured out a solution to this (or even a workaround), sharing that will be greatly appreciated.
thanks,
Mike
I have struggled with this on 2003 server and found that when I turned off firewall everything worked, then when turning firewall back on it didn't. I found the problem under firewall exceptions "File and Printer Sharing". When you go to edit the service, there are 4 entries, and when you check the scope they are set for your network subnet only. My problem was/is that we use multiple subnets and this machine did not match to the other machines trying to access it. If you find this is also your problem, and not the admin$ share issue (you can search against that), update the network subnets in a custom list (or if you're daring to attacks, allow any computer - bad idea). You only need to update ports 139 and 445 Hope this helps someone.
Related
In my organization a project has begun to install SCCM on every computer. My job is to filter out computers which do not have SCCM installed on them (that part is done), find out why and try to install.
Unfortunately, I’m inexperienced with SCCM logs and find it hard to locate the problems (if there are any) and there is a huge number of devices I have to check all by myself and accessing each computer’s C$ will take years.
The OS of the problematic computers are Windows 10/7/XP/Server 2016.
Can anyone help me with these issues please?
Thanks in advance
The client install logs on the local machine are here C:\Windows\ccmsetup\Logs. You could script something to pull the logs and dump on a network share.
You can pull the CMTrace.exe from the server install directory to read the logs.
They are most likely failing for the same reason, I would start with looking at the firewall and make sure WinRM is enabled.
There are 3 methods to installing the agent GPO, Login Script, or from the console.
I have computers where I want to run OpenCL apps remotely using a command line tool, something like the problem described here: http://devgurus.amd.com/thread/160690, but I am with nVIDIA hardware.
I have several computers with W7 and XP where I did install cygwin and OpenSSH. The XP ones, work OK with OpenCL, but not the W7 ones.
Is there any flag, trick, setting that can help be to overcome this problem of Windows? Or in SSHD server?
Found the solution myself:
The easyer way to overcome this problem is to use PSEXEC tool from sysinternals.
However, there are some problems with this tool too.
In order to work properly it is needed:
An account in the remote computer with proper rights (Admin preferable)
Launch PSEXEC in interactive mode (-i), otherwise the access to the GPU is not available.
Have a local user connected, or a local user was the last one to connect. If a RDP session is running or the last user connecting has been trough RDP it will likely not work too. Since the GPU will already be disabled.
I am open to accept anyone else's better answer.
Thank you!
I need to debug some C# code on a remote machine running XP Embedded. I did remote debugging on several occasions on different Windows operating systems and all worked well, but I think that the XP Embedded OS is missing something.
I'm popping my brains out in the last couple of days, reading and trying stuff, but nothing seems to work. So if you have been in the same situation and found a solution, please help. Here is what I did up to now:
Successfully established a remote debugging connection to an XP Professional environment, so I know that there's nothing wrong with my remote configuration.
Started the same services on the Embedded environment that are running on the Professional environment.
Configured DCOM permissions, firewall, local users with same name and passwords on both local and remote machines. Gave local users administrator rights.
Started msvsmon.exe both as an application and as a service, under the local user account, wich also has log on as a service rights.
Triple-checked that there is no other firewall between the machines that could drop remote debugging packets.
If I use the No authentication (native only) mode on the Embedded machine, the remote debugging works and I can see the processes. Otherwise, I get an error:
Unable to connect to the Microsoft Visual Studio Remote Debugging Monitor named '[NAME]'. The debugger cannot connect to the remote computer. This may
be because the remote computer does not exist or a firewall may
be preventing communication to the remote computer. Please see
Help for assistance.
Thank you for the time you took to read this and any suggestion may help. Thanks!
Can you use WireShark to capture the data going to the remote XP embedded device? If you get a TCP acknowledgement, at least you'll know it's not a firewall problem.
Did you tried to start msvsmon.exe with admistrator rights ? Maybe that is the issue, a post by John Robbins explains it : http://www.wintellect.com/CS/blogs/jrobbins/archive/2010/06/15/vs-remote-debugging-across-workgroups-or-domains.aspx.
I've read all related remote debug entries here and couldn't find an answer to my problem. I've trying to setup remote debugging to test a console app.
Dev Machine - Vista, VS 2008
Remote Machine - Win 2008
I've followed the steps in this article to configure it and I'm stuck with the following error when I try to list processes in remote machine under 'Attach to Process'.
"The remote procedure call failed and did not execute".
But in my remote machines 'Remote Debug Monitor' I see that the dev machine connection was established.
Can anyone provide me with any clues?
Whenever I run into this problem the first thing I do is disable the firewall on both computers. Firewall problems are the most common issue I run into with remote debugging and it's best to eliminate that problem from the start.
Do take care to turn the firewall back on when you're done diagnosing the problem :).
A fresh Windows XP SP3 install does not allow remote WMI access like Windows XP SP2 does.
If I follow the steps in the "How to troubleshoot WMI-related issues in Windows XP SP2" document at http://support.microsoft.com/kb/875605 I'm unable to get SP3 to respond to a remote WMI request.
Every request, even to the built-in Administrator account, a new account in the Administrators group, or even a new account not in the Administrators group but given access to remote DCOM & the WMI namespace as described in the Microsoft document all return error code 0x80070005, Access is denied.
To verify I didn't have a goofy system configuration, I installed a fresh Windows XP SP3 image (using the .ISO image from MSDN) and performed no configuration changes save enabling RemoteAdmin through the Firewall. The Access is denied behavior was seen in this scenario as well.
What changed in Windows XP SP3 to remote DCOM / WMI access and how best to enable it?
It turns out the issue wasn't specific to SP3, but rather the lack of these systems being in a domain.
If XP isn't in a domain then the "Use Simple File Sharing" option, found in the Folder Options control panel applet, works it magic. If this option is enabled (the default) all file sharing connections are done with the guest user credential, but this also is applied to incoming DCOM connections as well.
Disabling this option allows DCOM connections to be verified as expected.
Supposedly SP3 does not check 'Enable Distributed COM on this computer'. Get into Component Services (dcomcnfg.exe) Component Services, Computers. Right click 'My Computer' and go to properties. 'Default Properties' is the tab you want. I have also heard that changing the DTC Logon account to NT AUTHORITY\NetwerkService (note the e instead of an o) will work. You can find this under the MSDTC tab, Security Configuration following the same path to My Computer.
We solved something very similar by using these tricks. Hope this helps.
I'm not sure if RemoteAdmin is the one you need to turn off or not in the firewall.
One suggestion would be to turn off the firewall completely first and try that. If it works, then you know it is the firewall. If this is the case, then I would try adding port tcp 135 directly and try again.
You may also try using telnet [ip address of XP_SP3 machine] 135 and see if you can establish the connection.
Hope this helps.