I need to automate actions I do on a Remote Desktop. The au3recoder (which comes with Autoit) doesn't seem to record anything on the RDP.
Yes, Autoit works on RDP machines if you execute the file on that machine. If you want to use it from your own PC over the RDP connection that could get difficult.
You can't detect windows over RDP what makes most of the AutoIt functions useless.
You could click on positions with MouseClick(). It's not the most elegant version but it works for little things.
The Au3 Recorder never worked for my anyways, so you could also hardcode it yourself.
I recomend that you copy a file to your RDP machine to use all AutoIt functions.
Of course it is possible.
And you could use most of the "AutoIt" functions because they are C++ functions which windows have them all.
The most accurate way to do it is to use CMD through AutoIt to get most of the informations.
However the most elegant way would be using PowerShell.
Related
I am looking for the best way to execute code on a distant machine. Ideally, I am looking for a solution such as Cuda which provides the opportunity to allocate executions on GPU or CPU, but for distinct machine.
I tried distinct ways to do that :
I connect my machines with ssh, export my script, execut it. No particular issue, but not very handy. But maybe this solution could be optimise. Because I open my ssh connection with the terminal, or termius.
I try another way with mosh, same outcomes, but quicker.
Currently, I am working on a Spyder kernel to have a direct link in the place of execution.
I've seen there is also a possibility with a nohup connection, but I have to work on this solution to understand well the possibilities.
Everything works well, but I am looking for a more convenient solution.
Thank you in advance for your answers !
You could either use sshfs along to ssh to mount the remote filesystem on your machine it's easier than always copy the code by hand, if so I would recommend to use screen or something like that that if the connection breaks it offers no problems.
Personal I like to work with Visual Studio Code and the ssh fs extension for this purpose.
An other alternative is to work with X2Go. X2Go enables you to access a graphical desktop of a computer over a low bandwidth (or high bandwidth) connection.
I have access to (not authority over) a computing cluster which has R installed. Is there a way for me to use R-Studio on my local computer -- but have the code running on the cluster via SSH?
To clarify -- No I don't really have non-SSH access, no I can't install R-Studio (server or desktop) on the cluster.
In line with the hackish options #hrbrmstr mentioned...
If your aim is to run mostly non-interactive code, then you can probably establish an n-node parallel::makePSOCKcluster() on the remote machines and run each of your commands via parallel like commands. Similarly, you could use package::svSocket, see this neat demo on YouTube for more details than fit in a reasonable answer.
But, given that you said RStudio, I suspect you are thinking of interactive use, and the above would be doable (but painful). Nothing I know of will let you just pretend that the remote machine is the local machine (which is a pity to be sure). However you might be able to hack something together, with sink() etc and a server and client side loop, e.g. How to connect two computers using R?.
I'm looking for a way to develop some Unix scripts that will connect to a DOS box (Windows server 2012) and interactively execute DOS commands.
I'm comfortable with the Unix side (I'll almost certainly use Expect), but I'm "Windows illiterate" and am unable to find anything about connecting to Windows's DOS command line in this fashion. Is this even possible to do?
(FWIW, this is to enable us to control Tableau Server using its 'tabcmd' DOS command suite from our existing Linux environment.)
UPDATE 1:
I think another way of asking the question is: does Windows provide anything that is the equivalent of the Unix "remote shell", accessible from Unix?
There are no built-in tools to do this, although PsExec is a utility that can almost do what you want. PsTools are not a built-in, but are hosted on Technet. Some things to keep in mind:
PsExec works by actually remotely copying a file over to the Windows System32 folder (copying is one thing that is builtin ;)
Windows uses Kerberos for authentication. This depends on the computer you are running the command from being on the same Active Directory as the computer you want to control, with access set up from that side. Linux can use kerberos through third-party AD integration tools (like Quest Authentication Services, a commercial product), or also Centrify but there are no built-in tools that do it.
Psexec is not encrypted, meaning if you send commands containing sensitive data, they can be seen (though not the authentication part of it).
PsExec is obviously still a Windows utility. I have been able to get it to work using Wine, but only for a local account and after some tweaking with matching hostnames and stuff. It's possible that if you have authenticated using QAS or Centrify that your wine command will somehow pick it up, but I haven't tested it; I don't work where we use AD anymore.
Maybe the biggest problem is the difference of philosophy between the two communities. Windows doesn't use command line execution very often for remote administration. There is more focus on using your local utilities on a remote system (i.e., you can load a remote registry hive from RegEdit or browse the file system of a remote system using your local Windows Explorer program).
Overall, I think Keith's solution is actually the best, and the most straightforward.
I tried to run autorun.inf that I created but I cant get it to work. Is it even possible to do so or is it just for CD's. If not is there an alternative to do this or an equivalent?
This is all that I want it to do:
open=Launcher-Plus.hta
icon=Launcher-Plus.ico
Autorun.inf got blocked from all the new released Windows system after the massive removable device viruses took advantage of it. So the short answer is NO you can't do it anymore, not even on CD
I'm trying to setup automated GUI tests in ESXi Virtual Machines using TestComplete. The problem, as I understand it, is that when no remote desktop connection is made to the ESXi virtual machine, then it is impossible for TestComplete to perform screen captures and therefore automate the GUI testing. As far as I understand it, this is due to the fact that Windows does not generate any user interface when nobody is viewing it.
I'm sure other have experienced this problem. How did you solve it ? Are you using a third party computer which automatically launch remote desktop connections prior to running the tests ?
Would it be possible to launch a remote desktop from a head-less virtual machine to another to fake somebody viewing ?
Any other smarter solutions I haven't thought about ?
You should be able to log in to Windows on the VM's console using the vSphere client, then close vSphere, and Windows will still believe the user is viewing the console. Simple as that. :)
So there shouldn't be a need to involve remote desktop in the mix.
As long as your tests then run as that logged-in Windows user, you should be fine.
This technique has always worked like a charm for me with certain Watir, Selenium, and MS UI Automation tests that depend on having an interactive desktop.
If you need to reboot the VM automatically before/during the test, instead of logging in manually in the vSphere client, you can make Windows log in as an arbitrary user automatically - check the "control userpasswords2" command, or you can use the Sysinternals app "Autologin":
http://technet.microsoft.com/en-us/sysinternals/bb963905
Only catch with this technique is that you need to be able to launch your tests while not viewing the console on the VM, but it sounds like you've already taken care of that?
If you need a solution for launching your tests remotely, I highly recommend using Jenkins or Hudson to kick off tests/collect results from the VM. Jenkins has changed my life in this regard.
You may consider using the Network Suites functionality of TestComplete:
http://smartbear.com/support/viewarticle/16849/
It can open Remote Desktop connections on its own, control tests on remote PCs, and pull the logs back to the "master" project. This feature is designed to be used for distributed tests, and looks like it's just what you need.
As for opening RDP to a head-less VM, it should not be a problem - it's up to Windows to "think" about this. You just open RDP and it works even if there is no monitor attached to the remote PC/VM.
I hope this helps,
Alex
You can always use VNC with checking the option "Do nothing" when disconnecting viewer. This way you'll trick windows to generate the image.