deadlydog / AzureDevOps.WindowsScheduledTasks

An Azure DevOps extension for installing and uninstalling Windows Scheduled Tasks
MIT License
10 stars 3 forks source link

Scheduled Task Name Parameter #15

Closed mmlachak closed 4 years ago

mmlachak commented 4 years ago

On the remote servers that I want to update using your tasks, my Scheduled task is on a specific drive and folder. (D:\MyApps\tasks\REDNA.VendorTracking.Console)

How fdo I map this correctly to get the task to work. I have tried every combination. The physical task name is: REDNA.VendorTracking.Console.Tracking

Any help or guidance would be appreciated.

deadlydog commented 4 years ago

The easiest way to do it is to manually create the Windows scheduled task on the server, set it up the way you want and confirm it can run the application, and then export the scheduled task xml to a file, then delete the scheduled task from the server. You can then include that xml file in your source control and build artifacts, and use it at deploy time to create your scheduled task.

Let me know if that gets you going or not :)

mmlachak commented 4 years ago

The tasks have been running for over a year on the servers without no problem. I can export the task with no problem also. Problem is that the task has to NOT exists for it to be created. I want to control this process by Stopping, Disabling, copying or installing the task, Enabling and Starting. To do that I need the Scheduled Task as a parameter.

I do not see from your documentation that the install task does all of those steps. Am I mistaken?

deadlydog commented 4 years ago

You are correct that the Install Scheduled Task won't try and uninstall it first if it exists; you need to explicitly add an Uninstall Scheduled Task step to your pipeline. That does pose a problem if your scheduled task doesn't exist yet, as the Uninstall will fail saying it can't find the task. You can get around that enabling "Continue on error" for the uninstall pipeline task. I jotted down having those specific errors be treated as warnings, but never implemented it as nobody has every asked for it.

My typical deployment flow is:

  1. Uninstall scheduled task
  2. Delete scheduled task app's directory if it exists
  3. Copy the new version of the app to the directory on the server
  4. Install scheduled task
mmlachak commented 4 years ago

I still cannot get this to work. As the uninstall task requires a name, and that is what started this whole conversation. The whole issues stems from the fact that the service is running on a different drive then the standard C: drive. We isolate our apps this way for security concerns.

My flow is the same as you documented above

deadlydog commented 4 years ago

I take it you were able to get this figured out mmlackak? The drive/directory that the app to run on shouldn't make any difference; it's just a string field in the XML definition. You could put a completely bogus path in that and the task should still get installed; just when the task eventually runs it will die instantly with a "Could not find program" error.