How can I check if the Windows setup process is complete from a script? I have a Powershell script that runs on new builds which sometimes gets kicked off before the Windows installation is complete, but needs to wait until setup is complete to execute.
List all processes and ensure that WinDeploy.exe is not among them. If WinDeploy.exe is running, then Windows' setup is not yet complete:
Get-Process -Name windeploy
Note that when WinDeploy.exe stops executing, you will need to ensure that the system is not rebooting before continuing, and wait until it comes back up before continuing execution. For our environment, it was easier to use the VMWare API from our deployment system to wait until WinDeploy.exe was finished executing and also check that the guest was in the running state before attempting to execute the provisioning script.
If this is something that you have to run in a local script for whatever reason, consider using Powershell workflows which can be used across reboots.
Related
I am trying to find solution for the jenkins nodes to automatically connect to master in non headleass mode.
Here is what I have done so far
I have written batch script which calls the powershell script. Powershell script has series of commands to start the jenkins slave agent using jnlp.
This batch script is configured in Task Scheduler to run at the startup. The jenkins slave node is connected to master as soon as node starts up.
But execution of GUI test is not visible in the node when the test starts.
When I manually run this batch script from command line, it works fine i.e non headless mode and I can see the execution of GUI test.
I've read few articles about this kind of setup and none worked.
I also wrote a small piece of powershell script to allow a Windows Service to Interact with Desktop. This script runs after the batch script to start jenkins slave agent.
Task scheduler job is configured to Run as Administrator and I login as administrator to see the execution.
Since this batch script is running via Task scheduler I am guessing its running in a different session.
How do I solve it.
Try to put your script into shell:startup.
On a Windows 10 machine with the Jenkins slave under the user you need, press Windows+R (Run...) and type shell:startup and put your script into opened folder. It will run once the user logged in.
This is how you'll see console and any windows it spawns.
I just installed Jenkins 2.46.2 on a Windows 2012 Server \o/. It runs as a system service.
I created a job that execute a windows batch (.bat) script to build a code project. This batch results in executing 2 mingw32-make.exe commands to clean and then build a full binary from source code.
Executing the batch manually on the machine, located on the same filesystem (same workspace as used by the Jenkins' job, local disk - not network disk), the clean-build takes ~50 seconds.
But when executed by Jenkins, the job takes more than 20x more time longer! (~19 minutes). It terminates succesfully with the same behavior as executed manually in cmd.exe.
I changed the launch arguments for the jvm in the jenkins.xml file with "-Xmx1024m -XX:MaxPermSize=512m" options as I have read in the documentation to improve performance. But it does not fix anything :-(
Also when I monitors the CPU/disk/RAM usages they all stay very very low while building, so I deduce that brute performances of the machine are not in cause.
Whether I invoke the batch with call statement in the Jenkins job build step or not does not change anything : the job always last 19 minutes.
Can anybody help me to investigate why so slowness ?
Thanks in advance :)
I had a similar problem. I noticed that .bat files with echo Hello World ran fast and with no problem.
But once I tried to launch any grep.exe from a batch script, it took 24 seconds (in my case) to run even with no input files. If launched manually it finishes in no time.
I used grep.exe version 2.5.4 from MSys 1.0 distribution.
The solution in my case was rather unexpected - I updated grep to version 2.24, and now, being launched from Jenkins, it takes less than one second to process over 1 MB log file.
For a couple of day investigation, I finally find the cause.
In my case, it is the reason of Jenkins agent.
When I install Jenkins agent as a windows service in the slave agent, the consuming time is so huge,but when I try to start Jenkins agent via windows command line, the consuming time is as normal as executing the batch file manually.
My env:
master: CentOS7
slave agent: win 7
And I also test this case in a slave agent of win 10 for comparison.
The time executing via Jenkins is approximately the same as executing the batch file manually on the agent machine.
So I guess this is the compatibility issue between win 7 and Jenkins.
But for that the Jenkins official said that Jenkins not support win 7 anymore (Microsoft does not support Windows 7), we temporarily put it aside.
Anyway we find a way to conquer this. Hope this will help you for similar scenario.
I have been trying to configure regular automated backups to a shared network drive using the Windows Server Backup console. When I backup manually, it works, however it does not run on its own as scheduled. I have made sure to enable run backup while not logged in. There are no error messages when it does not run according to schedule, it just skips to logging the next scheduled backup as the next day.
I have also tried using the wbadmin command line. My script is similar to the following:
wbadmin enable backup –addtarget:\backupshare\myshare –include: c:\ –user:DOMAIN\mylogin –password:mypassword –schedule:19:00 -systemState -quiet -allowDeleteOldBackups -
I have not received any errors with my script and the windows command line acknowledges that there is a scheduled backup to run. However, the backup does not run and when I check wbadmin get status at the time it is scheduled, it will tell me there is no back up running at the moment with no error codes.
I am not sure why my back ups will not run as scheduled as they will run manually.
Any help would be greatly appreciated,
Thanks!
I’m going to assume that you’re running it with heightened privileges and for running the task you’re using a Domain Admin account, I would suggest running the command manually from command line and add in this argument “get status > \task.log”
I have a build job on jenkins that is building my project and after it is done, it opens an ssh shell script on a remote server and transfers files and then stop and starts a daemon.
When I stop and start the daemon from the command line on a RHEL server, it executes just fine. When the job executes in jenkins, there are no errors.
The daemon stops fine and it starts fine. But shortly after starting, the daemon dies suddenly.
sudo service daemonName stop
# transfer files.
sudo service daemonName start
I'm sure that the problem isn't pathing
Does anyone know what could be special about the way Jenkins is executing the ssh shell script that would cause the daemon start to not fully complete?
The problem:
When executing a build through jenkins, the command to start the daemon process was clearly successfully executing, yet after the build job was done, the daemon would suddenly quit.
The solution:
I thought for this whole time that it was jenkins killing the daemon. So I tried many different incarnations and permutations of disabling the ProcessTree module that goes through and cleans up zombie child processes. I tried fooling it by resetting the BUILD_ID environment variable. Nothing worked.
Thanks to this thread I found out that that solution only works for child processes executed on the BUILD machine. I.E. not applicable to my problem.
More searching led me here: Run a persistent process via ssh
The solution? Nohup.
So now the build successfully restarts the daemon by executing the following:
sudo nohup service daemonname start
Jenkins watches for processes spawned by the job and kill them to avoid zombie processes.
See https://wiki.jenkins-ci.org/display/JENKINS/ProcessTreeKiller
The workaround is to override the BUILD_ID environment variable:
BUILD_ID=dontKillMe
I modified this script from the net, which is suppose to install .exe applications for remote machines:
$m = Read-Host "Enter machine name"
$File = "c:\temp\office2007sp2-kb958194-fullfile-en-us.exe"
$product = [WMICLASS]"\\$m\ROOT\CIMV2:win32_Process"
$product.Create($File)
When I run this script, I have noticed that this program promptly creates a process in the remote machine with the application name office2007sp2-kb958194-fullfile-en-us.exe.
This can be checked in the task manager also.
But other than that, there is no way to find out if this is getting installed in the remote machine or not.
Is there a way to find out, if the installation is really happening?
Or does this script actually works?
Not a proper answer because I haven't tried remote process launching like that, but I have used psexec to launch processes on other machines.
If you are still having problems with your script you may want to check out ps_exec, it lets you execute processes on other machines as if it was your own. You can check the exit code of the process just like you would if you were executing the process locally.
It's offered as a free tool by microsoft: http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx