So we are trying to setup a Continuous Integration server at my company. What we need to do is svn update the working copy on the server, then build it, start the site using IIS express and then run Watin/Specflow tests on it. I'm using rake inside of CCNet to automate all of this. We are running CCNet as a service and logging in as a build agent because svn uses our domain login credentials in order to authenticate. I've been unable to call the command line "svn update --username user --password pass" because of this. Yet Watin needs to be run in an interactive mode, and the service won't let me . I'm able to get it to work if we manually log on to the server and run ccnet as command line. Unfortunately the Build Agent also logs out of that user account, closing any command lines with it (I don't know why they need it to do this but they do). So is it possible to run a service in interactive mode if its signed in as a user?
If you have access to two servers you can build (can also work from computer to server)
Automated remote desktop - in windows form
see this post http://www.codeproject.com/Articles/43705/Remote-Desktop-using-C-NET
from one server to log into the server you need to run the Watin tests on and in the scheduled task, have the tests to come on after the log in has happened. This then gives the impression that the service is interacting with the desktop.
If you need any more information let me know
Related
First off, I didn't have this issue until setting up my agent to run as a windows service.
My company has custom cmdlets we have built that are part of the default profile that is loaded when running powershell. I am using Jenkins to execute a batchfile that iterates a command over a series of machines. After settings up Jenkins to be a service, it no longer has access to those cmdlets leading me to believe the profile isn't being loaded. If I load the profile manually by running the profile script, it only seems to work on the first machine.
When setting up Jenkins as a service, I configured it to be the same user that I would manually run these scripts as if I were to login to the computer. I have verified it is using the proper user with $env:UserName.
I am at a loss as to why setting up jenkins as a windows service broke this. I could revert to using the command line to connect to Jenkins, but that doesn't always connect post server maintenance or after a power outage.
Did I configure something wrong or is there a way to load profiles instead of jenkins always running -NoProfile?
Update - I noticed when running $PROFILE it was set to a default profile location that did not exist. It seems when opening powershell manually on the machine it loads the AllUsersCurrentHost profile but this doesn't happen when using powershell from Jenkins when running as a service. I created the file location where it said it was using the profile and copied the default profile there and it works. I am still not sure why the behavior differs, but at least I found a solution.
I am working on a TFS CI build pipeline. The build includes execution of functional UI tests (Run Functional Tests) and the required accompanying preparatory test agent deployment step (Deploy Test Agent).
This build executed successfully in the past but spontaneously stopped working recently.
I initially ran into difficulty with the DTA task executing hanging:
Task 'SetupTestMachineForUiTests' on machine '[testVM]:5985' is taking time. Please Wait
I had encountered this issue with this build task before albeit intermittently. However, this time the step would not complete no matter how many times it executed. Eventually (~20 minutes), the step crashed out with the following error:
Task 'SetupTestMachineForUiTests' for machine [testVM]:5985's Error :
System.Exception: Stopping test machine setup as it exceeded maximum number of reboots. If you are running test agent in interactive mode, please make sure that autologon is enabled and no legal notice is displayed on logon in test machines.
Unfortunately, the DTA task only writes logs to the usual location on the test VM when the DTAExecutionHost.exe is manually closed on the server after the step has failed. The logs offer no clue as to what the problem might be.
One of the prerequisites for the DTA step to execute successfully is that AutoLogon is enabled on the test VM; I had done this with a simple PowerShell script, executed prior to the DTA task. In order to confirm that the test VM registry values had been correctly assigned (to enable auto logon, disable legal notice, screensaver etc) during my PowerShell script execution, I added a further PowerShell debug script to the build to output each relevant registry value to the build console (all are correctly assigned).
However, when I went to test remote login on the test VM, using the test username, the user creds are accepted but the following warning message shows:
To sign in remotely, you need the right to sign in through Remote Desktop Services. By default members of the Administrators group have this right. If the group you're in does not have the right, or if the right has been removed from the Administrators group, you need to be granted the right manually.
I believe this is the problem. However, the solution has so far eluded me.
I double- and triple- checked; the test user has been added to the
Remote Desktop Users group (also Administrators group).
I've also confirmed that both Administrators and Remote Desktop Users groups
have been granted 'Allow log on through Remote Desktop Services' user
rights.
In testing, I forced successful execution of the build by substituting my own username instead of the test user into the build definition (my user name is also added to RDU and Admin user groups on the server but I can successfully remote onto the box with my own creds); this build executed successfully.
I also inspected the other (possibly, probably) related user groups:
Srv_SeDenyInteractiveLogonRight (test user is absent)
Srv_SeDenyRemoteInteractiveLogonRight (test user is absent)
Srv_SeInteractiveLogonRight (test user present)
I've been fighting with this problem for days now; it's now become a major headache. I'd be very grateful for any insights that might help find a resolution.
Thanks for looking.
The problem was that the account had been added to the AD domain 'DenyInteractiveLogon' group. Adding the account to the local 'Remote Desktop User' and/or the 'Srv_SeInteractiveLogonRight' groups had no effect.
Removing the user account from the domain group resolved the problem.
I'm trying to automate the deployment of the solution my team is working on through TFS Build server. One of the steps which executes a PowerShell script on the target machine fails with the following error:
Microsoft ODBC Driver 11 for SQL Server : Login failed for user 'sa'..
The PowerShell script I'm trying to execute does in fact connect to multiple databases using the sa credentials. When I try to execute the same script passing it the exact same arguments by hand (i.e: executing the script from the target machine VM itself) it works like a charm. But when it is being executed as part of the build steps it fails with the aforementioned error.
Is there a way to further debug the issue? It would be great if there is a way to output trace statements from the script so I could have some insight on what is actually going on.
Usually all the related error should reflect in TFS build log. To narrow your issue you can try to connect to the TFS build agent with the credentials used for the build service and manually run the ps script.
If you execute the ps script with your own account, which will not help to the issue. Usually this kind of problems is related to permissions. Your build service account are lack of related permission. Try to add it to Administrator or SQL Administrator group and execute the build again.
I have followed this guide to install a jenkins slave on windows 8 as a service:
https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins+as+a+Windows+service#InstallingJenkinsasaWindowsservice-InstallSlaveasaWindowsservice%28require.NET2.0framework%29
I need to run a job that interact with the desktop (run an application that opens a browser etc.). So after I have installed the slave as a service (running jnlp downloaded from the master) I have changed the service "Log on" to "Allow to interact with display".
For some reason its only possible to enable this for the "Local System account" even though its recommended to run the service as a specified user, eg. jenkins.
But nothing happens when I execute the job, the browser is not opened. If I instead stop the service and just launch the slave through the jnlp file the job runs fine - the browser is opened.
Anybody had any luck interacting with the desktop when running a jenkins windows slave as a service?
Services run since Vista in Session 0 and the first user is now in Session 1. So you can't interact any longer. This is called Session 0 Isolation.
Microsoft explains this here and here. You have to use 2nd Program which uses IPC to communicate to the Service.
I had lots of issues running Jenkins in Windows using the service.
Instead I now disable the service and run it from CMD.
So open CMD.
cd C:\Program Files (x86)\Jenkins
java -Xrs -Xmx256m -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -jar
jenkins.war --httpPort=9091
To resolve it, first create Windows auto-logon as I explain here:
https://serverfault.com/questions/269832/windows-server-2008-automatic-user-logon-on-power-on/606130#606130
Then create a startup batch for Jenkins agent (place it in Jenkins directory). This will launch agent console on desktop, and should allow Jenkins to interact with Windows GUI:
java -jar slave.jar -jnlpUrl http://{Your Jenkins Server}:8080/computer/{Your Jenkins Node}/slave-agent.jnlp
(slave.jar can be download from http://{Your Jenkins Server}:8080/jnlpJars/slave.jar)
EDIT :
If you're getting black screenshots (when using Selenium or Sikuli, for example), create a batch file that disconnects Remote Desktop, instead of closing the RDP session with the regular X button:
%windir%\system32\tscon.exe %SESSIONNAME% /dest:console
Consider running the Java slave server directly at startup and then using something to monitor and restart should the server go down (e.g., Kiwi Restarter).
Please check the services (# TestNode) make sure the "Interactive Services Detection" service is STARTED, by default the startup type is set to Manual, you may like to set it to automatic as well.
After service started, when you run your test in the Test Node, you will see something like the below:
Click on it and choose view the message
You will see the activities happen there. Hope this helps :D
Note: If login with other account and cannot view the Interative Services Detection prompt, restart the service again.
My Jenkins Service runs as user "jenkins" and all I did was to create Desktop folders in: C:\Windows\system32\config\systemprofile\desktop and if 64 bit Windows also in C:\Windows\SysWOW64\config\systemprofile\desktop - then it runs perfectly.
Make sure that Desktop folders are created as such:
%WINDOWS%/System32/config/systemprofile/Desktop
%WINDOWS%/SystemWOW64/config/systemprofile/Desktop
Presence of those can sometimes be mandatory while running some Java software as a Service.
I'm writing a perl script for a website, and I need to be able to control VirtualBox via the website. I'm not sure where to start, or if I'm even trying to debug in the right area, but here goes.
My server is running IIS7 on Windows Server 2008 R2. I'm also running 2 virtual machines through the vboxmanage command line interface. These VMs are running under SERVER\administrator.
When I open my website, it requests a login. I login to the website as SERVER\administrator and click a link that calls my script using an xmlhttprequest. Now, normally, it doesn't matter what user I run these as, but with vboxmanage, if I run the command as a different user, the list of VMs is different. I tried whoami, which returned SERVER\administrator, but %DOMAINNAME%\%USERNAME% returns the domain that the server is connected to as dommainname and SERVER$ as the username. The vboxmanage command then fails.
On the website, impersonation is turned on. When I turn impersonation off, the whoami request changes to be iis apppool\website. Any ideas on how to get around this?
As a final note, I've thought about using runas, but since it prompts for a password, there's no way to call it through scripting (and that would be a poor security decision, I'd imagine).
This is an oft recurring, well-known and well-solved problem. Instead of having one big program dealing with requests from the Web and managing the VM (strong coupling), separate the concern and write two programs, each doing exactly one task.
The user facing program running in the Web server context can continue with limited privileges. The VM manager is a stand-alone program running with the necessary admin privileges, either repeatedly from the scheduler or as daemon/service.
Have the first communicate with the second over a message-queue.