There are some questions regarding this topic, but thought I'd ask my about my unique situation...
Background - We are attempting to execute a QTP script via Jenkins. Now, Jenkins is running on a Windows Server, on which we are having some QTP install issues (that topic is for another thread...). As a workaround, I am trying to execute a simple AOM VBScript invoking QTP on a remote client machine (running Windows XP) and execute the test on that machine...
Setup - Just for initial proof-of-concepts, a .VBS file located on a Windows 7 box (the "calling box") has the following command:
Set qtpApp = CreateObject("QuickTest.Application","WinXPMachineName")
Problem - I am getting the following error on the calling box:
ActiveX component can't create object: 'QuickTest.Application'
I have followed the instructions to set up QTP for remote execution on the Windows XP machine. Note that QTP isn't installed on the Window 7 box .
QuickTest Pro must be installed on the local machine (in your case, your Windows 7 computer) even though you'll ultimately launch QTP elsewhere. This is because Set qtApp = CreateObject("QuickTest.Application", "MyServer") summons the local installation of QTP to open. Once the local QTP is open, it should communicate with the remote server and instruct the remote server to begin the test cases.
So, yes, you will need QTP installed on the local machine. (This is not troublesome if you have concurrent aka 'floating' licenses. If you have the seat licenses, that means they are paying for each individual computer that QTP is installed on. If that's the case, I don't know what to recommend.)
An alternate method:
I've been wrestling with remotely-launching QTP test scripts, particularly by launching them through the Windows Task Scheduler (That way, you wouldn't need QTP on the local machine, only on the remote machine). Here are a few questions I've had that hopeful might blaze a trail:
How can I run a QTP test from the command line?
Remotely managing Scheduled Tasks on another computer: Access
Denied
Unable to remotely schedule tasks from the command line
I was using another automation tool than QTP but I faced the same issue.
I was told I had to have the software "QAWP" installed in both machines to be able to run it remotely, but my company was reluctant on buying a second license for just this and wanted another solution 'Cheaper one'. So:
In the test machine have a batch file that executes your tests.
Add a scheduled tasks in windows that calls your batch file.
from any other machine you can start the scheduled tasks using the command:
schtasks /run /s /tn
both launch and remote machines have to be in the same domain and logged in as the same user that you gave access in the DCOM settings
turn off firewall if possible or add qtp to the exceptions
works perfectly for me
Can anyone tell if Set qtApp = CreateObject("QuickTest.Application", "MyServer") works if working with QTP trail version?
I have QTP trail version on two Win7 64bit machine.
When I use the above code to start QTP on my remote machine form vbscript then it works.
But when i try executing it from QTP it fails.
I have the right DCOM settings and all administrative privileges on both machines and my QTP is also running as admin.
So does it only work when I have licence installed?
To add more info to whoever still looking for answer to invoke QTP/UFT in remote machines:
Using VBScript to invoke QTP/UFT tests in remote machine is old school approach. I would suggest you to use Jenkins. It has tons of advantages.
Check here for more details.
Related
currently I am writing a deployscript for our build system.
I have an ec2 machine that i want to push my installer to, install the program and then run the program (exe). The program is in fact a server that should run forever. I already tried doing this with Powershell Remoting, this is not satisfying because a permanent connection is needed (if the powershell remote session disconnects, the process terminates).
Now I am looking into Invoke-WMIObject, is this really the best way to go, or am I missing something obvious?
Requirement is that the whole build process can be run from a powershell script (which is executed by our build server).
The server is running windows 2008 Server R2
kind regards
You could run your server program as a Windows Service - just wrap it with one of available free service wrapper utilities like nssm. You can use PSRemoting to recreate and start the service on the remote server each build by running Stop-Service, & nssm remove, & nssm install and Start-Service.
Alternatively (though probably not so easily managed in your build), you could remotely create and run a task in Task Scheduler with Scheduled Tasks Cmdlets.
You can use PsExec from SysInternals, but that's a standalone utility. However, you can still embed the logic in your PS script. If you are still in need of WMI, then you might wanna check this. It includes snippets of VB scripts and a detailed explanation of what to do.
I am using a RDC Connection from my mac to connect to an application (on windows box) in client network. Is that possible to write a script which does the following:
Open ur RDC. (i am using CoRD for this where my VM credentials are saved in .rdp files.
Login to VM with valid credentials from your .rdp file.
Open your app on that VM (for ex: IE explorer)
Following code in my shell script will connect me to my VM.(First two steps are working)
open rdp://[username[:password]#]hostname
How should I automate third step?
Is there any other way than shell script?
If you install Jenkins on your Mac, then install the Jenkins slave agent on the Windows machine, you can remotely run any command you like on the Windows box via the Jenkins web UI, and get back the results as well. In that scenario there's no need to use RDC at all.
For some more background, see: https://wiki.jenkins-ci.org/display/JENKINS/Distributed+builds
This might be a simplistic answer, but AutoHotKey is something that will automate your 3rd step. Its free and pretty easy to script. You can have this in your start up routine for your VM, so when you log in, you can have this kick off your job.
I have used it before for testing some Java Swing components on Windows and its been pretty handy (Windows was running on a Virtualbox VM on my Mac).
Im working with VS2010 and TFS and the Coded UI tests (CUIT).
I created some CUIT and added them to several Test Cases in Microsoft Test Manager 2010.
These tests are executed in our build-deploy-test steps.
This looks as follows (simplified):
Build application
Deploy
2a. Set snapshot of the Virtual Machine to which the application will be deployed to the snapshot in which the application is not installed
2b. Install application
Run tests
Step 3 contains Coded UI tests, but they cannot be executed (will fail), since there is no active remote desktop connection, which they need to be executed.
Now I would like to add a build step 2c. That automatically connects to the Remote Desktop so that the Coded UI Tests kan be executed.
How should I create this step in the Process Template?
I attempted this myself by running a PowerShell script to connect to a machine via Remote Desktop (see here to see how to use the Remote Desktop command-line utility).
This didn't really work for me personally because I was running this script from the build machine - which I could only connect to via Remote Desktop - and so when I close Remote Desktop it would close the session on the build machine and thus I would not be able to obtain a remote desktop connection with my test environment (plus it wasn't ideal to have to launch Remote Desktop from the build machine).
Therefore, the solution I went with instead was to enable auto-logon on the test environment (there are various ways to do this, I can't remember how I did it, but it's easily Googled).
So in my PowerShell script, which launched from our build machine, I used a command to remotely restart the test environment. With auto-logon enabled, the test environment would start back up with an active session, then I could carry on with Visual Studio Coded UI testing. This worked for me without any issues.
The command I used was something like this:
Shutdown.exe /r \\mytestenvironment
Here is some documentation for it.. If you intend on using this command to remotely restart a computer, don't forget to give your machine permissions on the test environment, otherwise this command won't work.
I then launched a command to sleep for a few minutes, to give time for the remote test environment to start back up again (with an active session), then I launched the tests.
Personally, I used a PowerShell script but you could also use a DOS/Batch script if you are more familiar with that.
Also, are you trying to run the automated tests as part of a build process template?
Let me know if you need any further help.
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.
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.