Our team has ~80 Windows development machines, and activities of each developer are logged as text files on the local storage of those machines.
To analyze the logged activities, I want to gather all log files from those machines. Additionally, the log files are updated constantly, so It is desirable to gather files with the command-line from my machine.
I’ve searched and found some solutions, but all of those are not suitable for our situation:
We cannot use PsExec, because tcp/135 and tcp/445 are both closed (countermeasure for WannaCry).
Administrative share is disabled.
telnet service is not up and is banned by security reasons.
WinRM is disabled on those machines by default.
It is difficult to install new software like OpenSSH on those machines (because of the rule of this project)
RDP is the only way to connect those machines. (I have an account on all machines)
How can I copy files from remote Windows machines with command-line through RDP?
Or, at least, is there any way to execute a command on remote Windows machines with command-line through RDP?
I think you can do this, though it is very hacky :)
For a basic setup, which just copies files once, what you would need to do is
Run a script in the remote session when it logs in. I can think of three ways to do this:
Use the "Alternate Shell" RDP file property. This runs a specified program in place of explorer.exe on login; you can use it to run "cmd.exe /c [your script]" for instance.
If that doesn't work (e.g. the remote machine doesn't respect it), you might be able to use a scheduled task that runs the script on login, but perhaps only for a specified user, or maybe the script could check the WinStation type to make sure this is actually an RDP connection before doing anything.
It's also possible to do this by connecting in RemoteApp mode and using the script as your "application", but that only works for Server and Enterprise editions of Windows.
Enable either drive redirection or clipboard redirection on the RDP connection, to give you a way to get data out.
Drive redirection is much simpler to script; you just have the remote script copy files to e.g. "\\tsclient\C\logs".
Clipboard redirection is theoretically possible - you have the remote script copy, then a local script paste - but would probably be a pain to get working in practice. I'm only mentioning it in case drive redirection isn't available for some reason.
You would probably want to script to then log the session off afterward.
You could then launch that from command-line by running "mstsc.exe [your RDP file]". The RDP files could be programmatically generated if needed (given you're working with 80 machines).
If you want a persistent connection you can execute commands over, that's more complicated, but still technically possible. Two ways I can think of:
Use the previous method to run a program on logon, but this time create a custom application that receives commands using a transport that isn't blocked and executes them in the session. I've done this with WCF over HTTP, for instance; it's not secure, of course.
Develop and install a service on the remote machine that opens an RDP virtual channel, and a corresponding RDP client plugin that communicates with it. You can then do whatever you want across the connection. While this solution would be the most likely to work, it's also the most heavyweight and time-consuming to implement so it's probably a last resort.
Related
Hello i have 3 networked machine with a shared folder, i need a script on one of the machines to run a files on all 3 computers at the same time.
What is the best way to approach this?
PsExec from sysinternals
Utilities like Telnet and remote control programs like Symantec's PC
Anywhere let you execute programs on remote systems, but they can be a
pain to set up and require that you install client software on the
remote systems that you wish to access. PsExec is a light-weight
telnet-replacement that lets you execute processes on other systems,
complete with full interactivity for console applications, without
having to manually install client software. PsExec's most powerful
uses include launching interactive command-prompts on remote systems
and remote-enabling tools like IpConfig that otherwise do not have the
ability to show information about remote systems.
Note: some anti-virus scanners report that one or more of the tools
are infected with a "remote admin" virus. None of the PsTools contain
viruses, but they have been used by viruses, which is why they trigger
virus notifications.
http://technet.microsoft.com/en-gb/sysinternals/bb897553.aspx
You can use waitfor to synchronize.
At the targets use waitfor anysignalname It will wait, until this signal is sent.
At the host (or on another cmd-prompt at one of the three targets) use waitfor /SI anysignalname to send the signal.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 3 years ago.
Improve this question
Is there a way I can launch a RDP session to a remote Windows server, and perform a file transfer to the local computer? Versions of the remote Windows Server varies. Ranges anywhere from 2000 to 2008.
I've tried to look up solutions and it seems scattered everywhere. Some suggest using mstsc.exe, others suggest PowerShell / Java / ASP Net. I'm confused. Appreciate some guidance here.
Thanks!
Update Below: 17 Feb 2012
Thanks for all suggestions. Would like to add that the remote servers are securely locked down and I'm not allowed to install SSH servers, FTP servers, or shared drives. The only way for accessing the remote machine is through RDP, and these machines are also on separate VLANs to which only authorised users can use RDP to access these machines. I'm trying to create a script that can help authorised users to download the required files.
You can map a drive using remote desktop.
Options > Local Resources > More
Ctrl + C at the Remote Desktop, and Ctrl + V at local, if you not looking for any automated solution. (Please check RD Config to enable copy and paste)
Once you have mapped the drives you want using mstsc, you can use \\tsclient to access the file system of the local machine i.e the Terminal services client from which you have RDP'ed on to the remote box.
If all you are trying to do is copy file from a remote box, just do \\machine\c$\path etc or share the folder and do \\machine\share to get them. RDP is not necessary in this case.
Once you have mapped the needed drives as Andy says, you can execute remotely a LOCAL batch file every time you connect specifying it's local path (using \\tsclient\c to refer your local drive) in the Programs tab at RDP properties.
Remember to write cmd /c before that path.
The rdp connection will automatically close once the batch file ends, but you can add the pause command to the end to see what happened during execution.
Connecting this way, you can edit the batch file before connecting.
Make sure your remote Machine enabled PSRemoting by running the following command in PowerShell
Enable-PSRemoting –Force
From the client computer, run the following command to establish the connection.
net use "\\{RemoteIP}\c$" "{Password}" /USER:"{Username}" /persistent:no
Here after you can use Copy-Item, Delete-Item over the network.
Copy-Item [PACKAGEPATH]\* \\[COMPUTER]\c$\installers -recurse
In Client machine, Run->mstsc.exe-> Local Resources-> enable clipboard.
In remote machine-> windows run command (Windows Key + R).
Open cmd->(Taskkill.exe /im rdpclip.exe) type brackets command
You got "Success", then
Type same command prompt "rdpclip.exe"
Now copy and paste both, its working fine
You can copy and paste files over RDP, it works perfectly. See http://www.reddit.com/r/sysadmin/comments/1d6a1o/til_you_can_copy_and_paste_files_over_rdp/ for more info.
eug wrote what I thing is an extremely useful comment that seems to have overlooked by everyone:
You can very easily share a single folder by using subst to map it to a drive letter, and then selecting that drive in remote desktop.
Note that it's fairly easily to have problems with this method due to subst performing the mapping only for the user under which it is run.
So I recommend to run everything from a single command prompt:
Open a command prompt (Win+R -> cmd)
Type subst <lettertomap>: <pathtofolder>
Type mstsc (which launches Remote Desktop)
Keep in mind that the subst mappings are not persistent across reboots, of course, so this is mostly convenient for a one-time session of file transfer.
There are actually also other ways to do the mapping, see raymond.cc .
And yes, the mapping does seem to disallow access to the rest of the drive, although I wouldn't bet my life that it doesn't have chroot-like "vulnerabilities" (assuming it is supposed to be secure in the first place).
1) Install dropbox or equivalent cloud storage product and sync needed files that way between computers. Remember, you can allow only certain folders to be synced on specific devices (you don't have to sync the entire dropbox, just the folders you need)
2) If you are allowed to setup more than one user on the remote server, have a 2nd user and then have user2 session connect rdp session to user1. This will keep the user1's gui alive in the cloud without having to remain logged in to rdp locally.
This video should show you how to implement this 2 user setup on your server to hold an rdp session open. Note that this does 'permanently' use 1 rdp session until you decide to close it.
[markdown cannot embed video :( ]
Then use AmmyyAdmin AnyDesk on user1's desktop to connect and manipulate the desktop. This includes using AnyDesk's file manager's ability to browse any folder you need and copy. AnyDesk can be free if you connect via direct IP connection. Most vps servers have dedicated IP addresss or subdomain address so this should not be a problem. Good idea to password protect your AnyDesk login and which IDs have access to unattended remote connections. The AnyDesk file manager is a bit crude, but it works. Their big thing is simplicity and speed.
Note: Use portable mode only on the remote user's desktop; Do NOT fully install AnyDesk. Also, the CPU usage might increase to stream the desktop screen, somewhat related to the size of the RDP window. I am using 1280 x 2048 window with 4 cores and the CPU usage is 22-25% idle or moving things around. This might decrease if there is more video ram or graphics processor on the target server. But, if you only "browse files" (use only the file manager without streaming the desktop), CPU usage >0.3% idle and >1 avg% when transferring files (burst up to 5-6% when the file is finished uploading and the pieces are being finalized).
You'd have to write your own scripts (java, .net, c#/c++, AutoIT, etc) to launch AnyDesk locally and automate the connecting and downloading specific files.
This strategy is a bit more complex, but it should do the job. Not sure why microsoft rdp cannot have some simple, quick file manager like what ammyy admin AnyDesk has; oh well.
Add: Can also use AnyDesk or Teamviewer. Teamviewer became a lot more restrictive on what is considered to be "non commercial use", but Anydesk is secure, much smaller footprint, and if you can have a direct connection doesn't seem to care too much about usage. If you do need a license, it will be much lighter on the wallet.
AnyDesk works flawlessly without any installation required. In fact, if using in a server environment as I described above, no installation is recommended.
Edit: AmmyyAdmin is no longer recommended for several months now due to some security and technical concerns. Added AutoIT as a scripting capability to automate interaction with GUI/nearly any windows function.
I have a windows server 2003 up in the internet.
But sometime I need to restart it.
After restart, I want one of the applications to run.
I want to do this all programatically.
I can now remotely restart the server.
But the question is how can I ask that piece of software to be executed (more precisely, I want to execute a .BAT file to ask a tomcat to run)?
Because I don't want to manually log in to the machine and start that application. That is time consuming. Is there any possible way, once the machine is started, my application will be run as well?
If you're developing an application that should always be running on the server, you probably need to implement it as a Windows service. For C#, see the classes in the System.ServiceProcess namespace -- you will need to inherit from ServiceBase.
Alternatively, you can set the program to be run as a scheduled task on boot. See the Task Scheduler API to do this.
You can install Cygwin and then do it the same way we'd do it on a Linux box: via ssh, using keys.
OpenSSH is not part of the default Cygwin install, so be sure to select it. It's in the Net category.
Then, after you've installed Cygwin and sshd, read /usr/share/doc/Cygwin/openssh.README to learn how to set up sshd as a service, so it will answer requests automatically, without you having to start the ssh daemon manually.
Finally, set up keys, as described in the link above.
Part of the ssh protocol is a way to ask a remote machine to launch a program. Setting it up with keys lets you do it without needing a password.
You could try xCmd, which is a freeware app to run a command on a remote machine.
My interactive 32-bit Windows app (now moving from Delphi [Ent] 2007 to 2009) uses command-line interactions to spawn child processes that do computationally-intensive tasks, which in turn write text files that the GUI parent app parses and analyzes - resulting in an interactive graphical display of the results.
I have access to a multiprocessor (multi-user) Linux cluster (via ssh), and would like to off-load the heavy lifting to that cluster. My question is how to spawn the processes in Linux from my Windows app. I can envision using secure FTP to put and get files, but not sure how to spawn the child processes in Linux.
Some leads for further reading would be fine - but code/pseudocode would be ideal. I can imagine that this may be more about Windows-Linux interaction than Delphi.
if you have access to ssh, one option is to issue commands through that.
For example:
ssh user#host ls -l ~
will in the ssh terminal show the files in the user's home directory. I'm not sure if this is what you really want. But it would likely work.
If you do this, you almost certainly want to setup SSH password less logins
However, A more ideal solution would likely be to setup a daemon on the linux boxes whose sole job is to run specific long running tasks in the background and let you fetch the results later.
You're going to have to install something on the Linux machine to run the process. You might find some kind of clustering or batch job submission API you can install and access from Windows. You might have to code a custom server. You might be able to run everything over ssh if you can drive an ssh process from Windows and if you have sshd installed on the Linux side. But my preference would be to write a webservice or simple CGI script on the Linux side designed to take your arguments and data and return the result over plain old http (or https as the case might be).
One way or another, this is going to encompass more than just coding on the Windows side.
I would download the full "putty" package.
As well as the excellent secure shell terminal, it includes PSCP to transfer files securely and PLINK to remote execute commands over SSH.
Hint: you will need to set up the full public/private key configuration for PLINK to work without an annoying password prompt. There is a useful guide http://unixwiz.net/techtips/putty-openssh.html>here.
I've been trying to get psexec to run executables on remote machines from custom build tasks in visual studio. All of these commands work from the command line but running it from an application seems to be a problem. Some commands work, on other psexec hangs and consequently so do msbuild and visual studio 2005. I'm calling SharePoint's stsadm.exe in this case, but this problem occurs with a lot of programs, when running psexec from an application. There are lots of people having this problem, but there seems to be no solution, so my question is: Does anyone know a working alternative to psexec?
I've experienced 'hangs' when executing PSEXEC against a remote system, but I always attributed it to the security context in which the remote process was running under.
From PSEXEC help:
If you omit a username the remote
process runs in the same account from
which you execute PsExec, but because
the remote process is impersonating it
will not have access to network
resources on the remote system. When
you specify a username the remote
process executes in the account
specified, and will have access to any
network resources the account has
access to. Note that the password is
transmitted in clear text to the
remote system.
If your executing a process remotely, that then needs to access the database (stsadm.exe), then it could be failing trying to access the network resource, depending on how PSEXEC was executed. If thats the case, I'd imagine it would eventually time out and give some sort of resource unavailable message.
There are two things that generally done when executing deployment steps against a remote machine to prevent the behavior your describing:
Like rifferte mentioned, make sure all assets needed to
deploy are local to the remote
machine (copy files, etc) before
using PSEXEC to execute the script (*.bat, *.vbs, *.ps, etc) -
so that everything runs 'local' to
the remote machine.
Run PSEXEC using
a domain username/password when
executing it - note that this
information is passed in clear text
to the remote server.
There's always RCE.
RemCom is a small (10KB upx packed)
remoteshell / telnet replacement that
lets you execute processes on remote
windows systems, copy files on remote
systems, process there output and
stream it back. It allows execution of
remote shell commands directly with
full interactive console without
having to install any client software.
On local machines it is also able to
impersonate so can be used as a silent
replacement for Runas command.
You can try to have psexec call a bat program that executes what you need on the remote machine. I ran into this issue with installutil.exe. A simple bat file on the remote machine resolved it.
You should also share your experience on the sysinternals board. There may be something they can do in a future revision.