I am creating an scheduled task during installation of an application. The installer itself is running with administrator permissons:
SchTasks /F /create /tn "MyApp Start" /XML "D:\MyApps\start.xml" /ru "System"
This task is intended to start during system startup, which is working fine as long as the user who is logging in is the one who created the task.
In my special case the task should also run if another non-admin-user is logging in.
Currently the task is not running, if the non-admin-user is logging in. Even more, the task ist not visible to him at all.
The question is: How can I create a scheduled task as administrator
using DOS or PowerShell-comnmands
that runs with System priviliges
that starts even if a normal non-admin-user logs into Windows 7/8
Here is my xml-description of the task.
<?xml version="1.0"?>
<Task version="1.2" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
<RegistrationInfo>
<Date>2015-03-02T22:54:11</Date>
<Author>foobar</Author>
</RegistrationInfo>
<Triggers>
<BootTrigger>
<StartBoundary>2015-03-02T22:54:11</StartBoundary>
<Enabled>true</Enabled>
</BootTrigger>
</Triggers>
<Principals>
<Principal>
<UserId>S-1-5-18</UserId>
<RunLevel>LeastPrivilege</RunLevel>
</Principal>
</Principals>
<Settings>
<MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
<DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
<StopIfGoingOnBatteries>false</StopIfGoingOnBatteries>
<AllowHardTerminate>true</AllowHardTerminate>
<StartWhenAvailable>false</StartWhenAvailable>
<RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
<IdleSettings>
<Duration>PT10M</Duration>
<WaitTimeout>PT1H</WaitTimeout>
<StopOnIdleEnd>true</StopOnIdleEnd>
<RestartOnIdle>false</RestartOnIdle>
</IdleSettings>
<AllowStartOnDemand>true</AllowStartOnDemand>
<Enabled>true</Enabled>
<Hidden>false</Hidden>
<RunOnlyIfIdle>false</RunOnlyIfIdle>
<WakeToRun>false</WakeToRun>
<ExecutionTimeLimit>PT72H</ExecutionTimeLimit>
<Priority>7</Priority>
</Settings>
<Actions>
<Exec>
<Command>D:\MyApps\start.bat</Command>
</Exec>
</Actions>
</Task>
Do you have any suggestions?
Best Regards
Tobias
Tobias,
I actually use the built in Windows Task Scheduler to set up these types of operations. I find it alot easier than using CMD and it has all the options, features, triggers, etc that you may be looking for. I use it to draft tasks and eventually push them onto our network. Not to mention it can be accessed under normal and admin user rights by default.
Hope this points you in the right direction.
Mike.
Related
To test our desktop application we are using TestComplete/TestExecute.
We have a Master project that is started on a Management machine.
This Master project doesn't require interaction with the Desktop, it is not testing our App.
This project will start the Slave remote project (actual UI tests of our app that require Desktop Interaction) on different VMs through TestExecute directly.
We are currently moving our Build process to TeamCity. On this Management machine we have a Build Agent from TeamCity. The Build Agent is running as service with a System Account (not the Local System Account).
We are not using the Local System Account (that can interact to the Desktop) because we need a domain account to access domain resources. And we don't want to start the Agent as a process, we want to keep it at a service.
Right now, we can't start TestExecute directly from TeamCity because TestExecute requires an interactive session and the Account of the Build Agent can't interact with Desktop.
We tried with a script (executed from TeamCity) to create a PSSession with a normal user that have access to Desktop and start TestExecute from this PSSession. But this is not working either.
Here is the exception that we had with both cases (directly and through PSSession):
Start-Process : This command cannot be run due to the error: This operation requires an interactive window station.
At line:3 char:9
+ Start-Process "D:\SmartBear\TestExecute 12\Bin\TestExecute.ex ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [Start-Process], InvalidOperationException
+ FullyQualifiedErrorId : InvalidOperationException,Microsoft.PowerShell.Commands.StartProcessCommand
Does anyone have a solution to start tests with TestExecute from TeamCity ? As I said this project doesn't need to interact with desktop, it will start the UI test on different VMs through TestExecute directly.
Or is it possible for a domain system account (like the one we are using) to interact with the Desktop ?
Inside the installation directory of TestExecute, you can find the manifest File TCLauncher.exe.Manifest :
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<!-- Here is the relevant part -->
<requestedExecutionLevel level="asInvoker" uiAccess="true">
</requestedExecutionLevel>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
You can configure the uiAccess to false.
If you don't use the TCLauncher, but directly TestExecute.exe, there is also a Manifest file, with the same section <Security> that you can configure.
You also can specify the level, from asInvoker to highestAvailable, but you might be prompted by the UAC.
The easiest thing you can do is to run the master project from Team City and the master project will invoke UI tests on slave machines. Since the master project does not require access to UI elements, there will not be any problems running it within a non-UI session.
We have scheduled a Windows Task to kick off some custom code (as an executable) that checks for existence of a file every 15 minutes.
If the file is eventually found, our service does some processing on it. Here's the rub: after the file is processed, the business requires that Task Scheduler stops these 15-minute checks until the next day.
Is there a way to insert logic into Windows Task Scheduler to stop running its trigger once some condition is met? Or is there a better way to architect this process?
We are using Windows Server 2008 R2 Standard SP1 to run this.
How to end a scheduled task:
A. To terminate a currently running task (i.e. one that shows up in Task Scheduler -> "Display All Running Tasks) from the command line:
schtasks.exe /End /TN "My task name"
B. To stop a scheduled task from being triggered to run in the future:
schtasks.exe /Change /TN "My task name" /DISABLE
C. To re-enable the task:
schtasks.exe /Change /TN "My task name" /ENABLE
More details are available by typing: schtasks.exe /Change /?
D. To ask a process to terminate (here: Notepad, but use the name displayed in Task Manager -> Processes\Image Name) that does not terminate when you run A. above:
taskkill.exe /IM Notepad.exe
E. To forcefully terminate a process that does not terminate when you run D. above:
taskkill.exe /F /IM Notepad.exe /T
Note: Using taskkill isn't a clean way of ending a process. You can read more in this post and in the article it links to.
How to set this up in Task Scheduler for your described situation:
Instead of having your task run the custom .exe directly, change it to run a script (e.g. a batch file, PowerShell script, Python script, etc.) which in turn:
Triggers the custom exe, then
Tests whether the file was found and "processed", then
Invokes command B. above to stop it from running again.
Add a second task that runs every morning (check "Run whether user is logged on or not) that re-enables the scheduled task by invoking command C. above.
Note: To invoke schtasks.exe requires elevated privileges, so set the task that executes that command to "Run with highest privileges".
How to detect that the file has been processed:
Have your custom .exe to add a Registry entry when it ran successfully. Your script can look for that entry using e.g. reg.exe (type REG QUERY /? for details).
There are other ways (e.g. posting a Windows event, sending a message, etc.), but using the Registry is an easy mechanism for a simple script to use.
Don't disable the task from directly your .exe. Keep the application and its invocation separate. That will also save you from having to recompile if you want to disable the task differently later.
I'd like to know if there is a way to reload the configuration file of the oozie job without restart the oozie job ( coordinator ).
Because the coordinator actually runs many our tasks, maybe sometimes we only need change one line of the job configuration file, then make the update , without disturbing other tasks.
Thank you very much.
The properties of oozie coordinator can be updated using below command once the coordinators start running. Update the property file in unix file system and then submit as below.
oozie job -oozie http://namenodeinfo/oozie -config job.properties -update coordinator_job_id
Note that all the created coordinator versions (including the ones in WAITING status) will still use old configuration. New configurations will be applied to new versions of coordinators when they materialize.
the latest oozie 4.1 allows to update coordinator definition. See https://oozie.apache.org/docs/4.1.0/DG_CommandLineTool.html#Updating_coordinator_definition_and_properties
Not really (well you could go into the database table and make the change but that might require a shutdown of OOZIE if your using an embedded Derby DB, and besides probably isn't advisable).
If you need to change the configuration often then consider pushing the value down into the launched workflow.xml file - you can change this file's contents between coordinator instantiations.
You could also (if this is a one time change) kill the running coordinator, make the change and start the coordinator up again amending the start time such that previous instances won't be scheduled to run again.
Not really :-)
Here is what you can do.
Create another config file with properties that you want to be able to change in hdfs.
Read this file in the beginning of your workflow.
Example:
<action name="devices-location">
<shell xmlns="uri:oozie:shell-action:0.1">
<job-tracker>${jobTracker}</job-tracker>
<name-node>${nameNode}</name-node>
<exec>hadoop</exec>
<argument>fs</argument>
<argument>-cat</argument>
<argument>/path/to/config/file.properties</argument>
<capture-output/>
</shell>
<ok to="report"/>
<error to="kill"/>
</action>
<action name="report">
<java>
...
<main-class>com.twitter.scalding.Tool</main-class>
<arg>--device-graph</arg>
<arg>${wf:actionData('devices-location')['path']}</arg>
<file>${scalding_jar}</file>
</java>
<ok to="end"/>
<error to="kill"/>
</action>
Where the config file in hdfs at /path/to/config/file.properties looks like this:
path=/some/path/to/data
I am trying to install a windows service using MSBuild and CCNET. I am using MSBuild Extension pack WindowsService
task to install and start the windows service as part of automated build. The script section look like this
<!--install service-->
<MSBuild.ExtensionPack.Computer.WindowsService TaskAction="Install" ServiceName="$(PrServiceName)" ServicePath="$(PrServicePath)" User="$(User)" />
<!--set service to run automatically on restart-->
<MSBuild.ExtensionPack.Computer.WindowsService TaskAction="SetAutomatic" ServiceName="$(PrServiceName)" />
<!--start service-->
<MSBuild.ExtensionPack.Computer.WindowsService TaskAction="Start" ServiceName="$(PrServiceName)" ServicePath="$(PrServicePath)" User="$(User)" />
Now as soon as the the first task runs to install the service, it fails with the following error
E:\Data\cc_temp\Projects\cubic\intranet\pr\pr.build (137,3): error : Install Service failed with code: 'AccessDenied'
I assume this is because the script is running under cruise control service user account which does not have the appropriate permissions for installing a windows service.
I would just like to give minimal permissions to the cruise control user account instead of giving the full administrative rights.
Does anyone out there knows how can i achieve this?
Awaiting
Nabeel
Nabeel you are on the right track, it has to be a permissions issue. We do this all the time in our build using the same tools and it works. Have you checked to see which account the service is running as? and using the same user account to run your cruisecontrol? at least then you would possibly prove/disprove the permissions issue.
I'm trying to decide which side I'm on in the MsBuild vs. Nant war. I'm starting with: stop a service, deploy some files, restart the service. Just from looking at these two links, that is much easier to do in Nant.
MSBuild: Example of using Service Exists MSBuild task in Microsoft.Sdc.Tasks?
<target name="service_exists">
<script language="C#">
<references>
<include name="System.ServiceProcess.dll" />
</references>
<code><![CDATA[
public static void ScriptMain(Project project) {
String serviceName = project.Properties["service.name"];
project.Properties["service.exists"] = "false";
project.Properties["service.running"] = "false";
System.ServiceProcess.ServiceController[] scServices;
scServices = System.ServiceProcess.ServiceController.GetServices();
foreach (System.ServiceProcess.ServiceController scTemp in scServices)
{
etc...
Nant: http://ryepup.unwashedmeme.com/blog/2007/01/04/restart-a-windows-service-remotely/
<!-- Send the stop request -->
<exec program="sc.exe">
<arg line="\\server stop shibd_Default"/>
</exec>
<!-- Sleep a little bit, to give the service a chance to stop -->
<sleep seconds="5"/>
<!-- Send the start request -->
<exec program="sc.exe">
<arg line="\\server start shibd_Default"/>
</exec>
I wonder if the SO community agrees with me. Is it much easier to get basic things like this done in Nant? Sure looks that way. C# code in a CDATA block? WTF?
Our current build process is a) lots of bat files b) lots of cursing. I'd really like to find a good replacement, but that MsBuild stuff looks like a world of pain to my eyes. I'm thinking the way to go is to build scripts in Nant, then use MsBuild to do any .NET builds that need to be done.
One important question: which one is better at catching errors in the script before the script is run? I was thinking of rolling my own here and that was very important part of it: line up all your data and make sure that it makes sense before attempting to run.
In msbuild you could also use the ServiceController task that is packaged in the msbuild community tasks.
You can execute sc.exe using MSBuild every bit as easily ...
<Exec Command="sc.exe \\server stop shibd_Default" />
By default this will "fail" if the exit code (of sc.exe) is non-zero, but that can be customized.
With Nant, there are 2 other ways to stop a service, and one is able to track an error.
First one (using Net Stop):
<exec program="net" failonerror="false"><arg value="stop"/><arg value="${serviceName}"/></exec>
Second one (much cleaner):
<servicecontroller action="Stop" service="${serviceName}" if="${service::is-installed(serviceName,'.') and service::is-running(serviceName,'.')}" />
Note that the second line verifies that the service already exists and is running, which allows to track any weird error.
In addition to #nulpptr's answer for MSBuild, if you don't have the option of using the community tasks, you might have to resort to a hack to wait for your service to stop before moving on. If you have the resource kit you can use the EXEC task with the sleep command.
No resource kit? Use the ping trick...
However, if you don't have the resource kit, you can use the ping trick to force a delay. For instance, the following will stop your service using the sc command, and then pause for about 5 seconds:
<Exec Command="sc.exe \\server stop shibd_Default" ContinueOnError="true" />
<Exec Command="ping 127.0.0.1 -n 5 > nul" ContinueOnError="true" />