Chat now with support
Chat with Support

Active Roles 7.2.1 - Administrator Guide

Introduction About Active Roles Getting Started Rule-based Administrative Views Role-based Administration
Access Templates as administrative roles Access Template management tasks Examples of use Deployment considerations Windows claims-based Access Rules
Rule-based AutoProvisioning and Deprovisioning
About Policy Objects Policy Object management tasks Policy configuration tasks
Property Generation and Validation User Logon Name Generation Group Membership AutoProvisioning E-mail Alias Generation Exchange Mailbox AutoProvisioning Home Folder AutoProvisioning Script Execution User Account Deprovisioning Group Membership Removal Exchange Mailbox Deprovisioning Home Folder Deprovisioning User Account Relocation User Account Permanent Deletion Group Object Deprovisioning Group Object Relocation Group Object Permanent Deletion Notification Distribution Report Distribution
Deployment considerations Checking for policy compliance Deprovisioning users or groups Restoring deprovisioned users or groups Container Deletion Prevention policy Picture management rules Policy extensions
Workflows
Understanding workflow Workflow activities overview Configuring a workflow
Creating a workflow definition Configuring workflow start conditions Configuring workflow parameters Adding activities to a workflow Configuring an Approval activity Configuring a Notification activity Configuring a Script activity Configuring an If-Else activity Configuring a Stop/Break activity Configuring an Add Report Section activity Configuring a Search activity Configuring CRUD activities Configuring a Save Object Properties activity Configuring a Modify Requested Changes activity Enabling or disabling an activity Enabling or disabling a workflow Using the initialization script
Example: Approval workflow E-mail based approval Automation workflow Activity extensions
Temporal Group Memberships Group Family Dynamic Groups Active Roles Reporting Management History
Understanding Management History Management History configuration Viewing change history
Workflow activity report sections Policy report items Active Roles internal policy report items
Examining user activity
Entitlement Profile Recycle Bin AD LDS Data Management Managing Configuration of Active Roles
Connecting to the Administration Service Adding and removing managed domains Using unmanaged domains Evaluating product usage Configuring replication Using AlwaysOn Availability Groups Using database mirroring Creating and using virtual attributes Examining client sessions Monitoring performance Customizing the console Using Configuration Center Changing the Active Roles Admin account Enabling or disabling diagnostic logs Active Roles Log Viewer
Using regular expressions Administrative Template Communication ports

Run the workflow on a schedule

Workflows > Automation workflow > Automation workflow options and start conditions > Run the workflow on a schedule

If you select the Run the workflow on a schedule option, then you can choose from the following options to run the workflow:

  • One time  Lets you choose the date and time to run the workflow.
  • Hourly  Lets you choose the date and time to run the workflow for the first time, and the recurrence interval (in hours and minutes) for the workflow. Thus, an interval of 1 hour causes the workflow to run every hour and an interval of 2 hours causes the workflow to run every other hour.
  • Daily  Lets you choose the date to run the workflow for the first time, the time of the day to run the workflow, and the recurrence interval (in days) for the workflow. Thus, an interval of 1 causes the workflow to run every day and an interval of 2 causes the workflow to run every other day. The workflow will start at the specified time each day.
  • Weekly  Lets you choose the date to run the workflow for the first time, the time of the day to run the workflow, the days of the week on which to run the workflow, and the recurrence interval (in weeks) for the workflow. Thus, an interval of 1 causes the workflow to run every week and an interval of 2 causes the workflow to run every other week. The workflow will start at the specified time on each of the specified days.
  • Monthly  Lets you choose the date to run the workflow for the first time, the time of the day to run the workflow, the months in which to run the workflow, and the day of the month on which to run the workflow. You can choose either the number of the day, or the first, second, third, fourth or last occurrence of a certain day of the week day during the month. The desired day of the week can be selected from a list.
  • When the Administration Service starts  Causes the workflow to start immediately after the Active Roles Administration Service has started up. This option applies to the Administration Service identified by the Run the workflow on setting.

Server to run the workflow

Workflows > Automation workflow > Automation workflow options and start conditions > Server to run the workflow

When started by a schedule, the workflow runs on a certain instance of the Active Roles Administration Service. The instance is identified by the Run the workflow on setting. This setting indicates the name of the computer running the Administration Service. You can choose the desired computer from the Run the workflow on list.

Allow the workflow to be run on demand

Workflows > Automation workflow > Automation workflow options and start conditions > Allow the workflow to be run on demand

If you select the option Allow the workflow to be run on demand, users can run the workflow manually, regardless of a schedule. This option allows a user to run the workflow at any time if necessary. A workflow can be started on demand from the Active Roles console or Web Interface, by choosing the Run command on the workflow definition object. For details, see Running an automation workflow on demand later in this document.

Active Roles normally allows only one instance of the workflow to run at a time. However, you can change this behavior for the case of running the workflow on demand. The following options are available:

  • If the workflow is already running, then do not start a new instance.
  • If the workflow is already running and a new instance is started on demand, then run the new instance in parallel.

The second option allows a new instance of the workflow to be started on demand even though the workflow is already running. This option applies only to the case of running the workflow on demand. In the case of a scheduled run Active Roles allows only one instance of the workflow to run at a time.

“Run as” options

Workflows > Automation workflow > Automation workflow options and start conditions > “Run as” options

The “run as” options determine the user account that the workflow runs under. Click the “Run as” options link on the Workflow Options and Start Conditions page to view or change the account setting. You can choose from the following options:

  • The service account of Active Roles  The workflow runs under the service account of the Administration Service that executes the workflow.
  • The account of the user who started the workflow  The workflow runs under the Windows account of the user who requested the operation that started the workflow.

All activities within the workflow normally run under the account identified by the “run as” options for the workflow. However, each activity can be configured to use individual “run as” options. The property page for the activity contains the “Run as” options link allowing you to override the workflow “run as” setting on a per-activity basis.

When running under the account of the Administration Service, the workflow activities have the same rights and permissions as the Administration Service itself and thus can perform any tasks allowed for the Administration Service.

When running under the account of the user who started the workflow, the activities can perform only the tasks that Active Roles allows for that user account. The Administration Service processes the activity operation requests as if they were submitted by that user via an Active Roles user interface, so the activities have the rights and permissions the user account is given in Active Roles.

Related Documents