workflow trigger not an Active Roles operation

Question

Hi, 
 
 I'm using Active Roles 7.5 and I'm looking for assistance on creating a workflow (on demand or automated) where the trigger isn't initiated within an Active Roles operation. We have our computers sorted into Operating system and type (desktops, laptops, tablets) and I'd like to automate a process where if one is updated from Windows 10 to Windows 11 the move will be done for us. I have a series of if-else operations to do the sorting that seem to work perfectly when we test with something like changing the description field but the operating System isn't one that can be altered, so the trigger won't work. Changing the description in our Active Directory didn't trigger the workflow so I know using a Modify to operatingSystem attribute won't work either, which is what I'd originally intended but I assume because the change to OS won't be a manual change through Active Roles, the same would happen where the workflow would never be triggered. I'm thinking of using an automated workflow to run a couple of times a day instead but I'm not sure how to get it to check the Windows 10 OU and identify the computers on Windows 11 to know it has to move those ones. Has anyone done something like this before that may be able to offer advice please? Will I maybe need to use a Powershell script to spit out a csv of the computers that need to be moved and then feed it back into the if-else bit I already have set up, or do the if-else within the powershell and just have a workflow that runs the script? 
 I hope I've explained that well enough! Any ideas will be great. 
 Thanks 
 Charlene

JohnnyQuest · Accepted Answer

I often use Managed Units to dynamically group together objects into sort of a "queue" to be acted upon by scheduled Automation Workflows. Try creating a Managed Unit (MU) to collect together the objects meeting your required criteria - the membership rule of the MU is where you will define your criteria - e.g. Operating System contains Windows 11 . Then from a script-based enumeration point of view, you just treat the Managed Unit as a "-SearchRoot" just as you would an OU. Here's a snippet to give you an idea of how this might work Get-QADComputer -proxy -SearchRoot <DN of Managed Unit> | foreach { 
 # Do something with each of the computers returned from the Managed unit enumeration # Optionally clear your "queueing" attribute (see below) 
 } If your script already alters one of your criteria attributes then the processed objects should just "fall out" of your Managed Unit. If not, then I often use a Virtual attribute to "queue" objects and then clear it at the end of my script to drop the processed objects out of my "queue" Managed Unit. 'Hope this helps.

Stu.Pollock · Answer

Hi charleneforbes 
 For a non-scripted option, you could use a workflow, with a series of Search Activity steps. The below is a collection of "Search", "If/Else" and "Move" activity steps. 
 
 Where in an automation workflow you'd 
 
 Search for a list of all your workstation OUs starting at Domain\Workstations (in my case, I'd have "Domain\Workstations\Windows 11" and "Domain\Workstations\Windows 10"), then for each OU found 
 
 Search for all workstation contained directly in the current found OU 
 
 Then check if the Workstation is in the correct OU, by comparing the Found object "Get Workstation OUs"'s description value to the current workstations operatingSystem property 
 If it does match, I move on and check the next workstation (1a) 
 If it does not match, I search for an new OU under "Domain\Workstations" 
 
 If an OU is found where the description matches the workstations listed Operation System, I move the object to that OU ...

You could also play around with the search task for 1a, to only return computers that dont match the description, as the method above would check every workstation, including the ones in the correct OUs, which for large environments may take a while. Also bear in mind, in this example you'd need to ensure an OU exists with a description for each possible value of Operating System in your environment, otherwise the computer would be left where it was. 
 
 Alternatively, as JohnnyQuest suggests you could use MU's, and a script module to do the changes, and move according to which ever business rules you need.

Endpoint Privilege Management

workflow trigger not an Active Roles operation

Top Replies