Combining Sync tasks and Scheduled tasks into one "item" to make running manually much simpler.

As a follow-up to this, I can see these attributes when I pull in a scheduled task:

Connect-QADService -Service "myServerName" -Proxy

$arsScheduledTask = Get-QADObject -Type edsScheduledTask -Identity "TestTask" -IncludeAllProperties

The following attributes are found: $arsScheduledTask.edsvaExecuteNow = null and $arsScheduledTask.edsaforceexecution = False

Can this be used to run a scheduled task from Powershell externally? Will setting one of these to true or 1 tell the server to run the task now?

You can definitely fire your AR scheduled tasks with PoSh as you suggest.  

Depending on whether your scripts are modifying AD properties or not, if they are you might consider using AR Change Workflows which would react to attribute changes being made by the scripts and thus help manage your sequencing.

This is one of those cases where the devil is very much in the details as far as solutioning the best combination of approaches.

Thanks. Yes they are modifying AD properties but at this time, I kind of just wanted to combine what is already tried and true (tested) but put it together into one manually run script so that when things fail overnight the entire process can be run with the click of a button. So far I have figured out how to run the scheduled workflows, I am still stuck on how scheduled tasks can be run inside this same script. Is it as simple as querying for the Scheduled Task (like I did above) and then setting a bit to rerun it right now?

I like your idea of using change workflows to update this entire overnight process. I will look into that for a future cleanup of this process.

Here's a snippet for you for firing a scheduled task:

set-qadobject -proxy -identity "CN=Test Task,CN=Scheduled Tasks,CN=Server Configuration,CN=Configuration" -objectAttributes @{edsvaExecuteNow=$true}

Thanks. Will test this out now.

Interesting thing I noticed today, it doesn't appear that the ARSConnection value does what I thought it did. I thought that using it would start the scheduled task on a particular server. It doesn't. It starts from the server you set the executenow attribute from. Is there a way to start the job from a particular server?

$task_fullname = "myScheduledTask"
$servicename = "ARSServerNumber1"
$arsConnection = Connect-QADService -Service $servicename -Proxy
$arsScheduledTask = Get-QADObject -Identity $task_fullname -IncludedProperties  edsaLastRunTime,edsvaScheduleDescription,edsaLastActionMessage -Connection $arsConnection
Set-QADObject -identity $task_fullname -objectAttributes @{edsvaExecuteNow=$true} -Connection $arsConnection

In your line 3, why don't you specify the AR server you want to use in the $servicename variable?  So if you want to run the task on Server1, connect to Server 1 and set the ExecuteNow.  Or maybe am I misunderstanding what you are seeing?

That's actually what I am doing. This script is running from ARSServerNumber2 but connecting to ARSServerNumber1 to start the task. When I look in the event log for ARSServerNumber1 I don't see the update to the object. Checking ARSServerNumber2 I DO see the update to the object. Could this be defaulting to the local server because of something I have done ahead of this in the script? I assumed if I told it to use ARSServerNumber1 it would use it. But it is not. One other thing, the scheduled task is also configured to run automatically from ARSServerNumber1 so I thought that might help. It did not.

Can you clarify this comment - my interpretation is in the [ ].

This script is running from ARSServerNumber2 but [I am] connecting to ARSServerNumber1 to start the task.

To confirm, in your code above, you believe the ARS Connection is being made to server 1?

It's odd to me that you say the script is configured with an affinity to Server 1 yet you see it running on Server 2.  That's counterintuitive.  

I am running scheduled tasks that currently run from two different servers all through one script. Some of them run from server 1 and some of them run from server 2. Server 2 is also a sync server so that was the reason it was picked to do this entire job. Three sync workflows and four scheduled tasks have been combined together to run under one script. {I am] is referencing the line #3 in the script when I say I am connecting to server 1.