2010 Quest Software, Inc. ALL RIGHTS RESERVED. Trademarks. Third Party Contributions

Transcription

1 6.7 Feature Guide

2 2010 Quest Software, Inc. ALL RIGHTS RESERVED. This guide contains proprietary information protected by copyright. The software described in this guide is furnished under a software license or nondisclosure agreement. This software may be used or copied only in accordance with the terms of the applicable agreement. No part of this guide may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording for any purpose other than the purchaser's personal use without the written permission of Quest Software, Inc. The information in this document is provided in connection with Quest products. No license, express or implied, by estoppel or otherwise, to any intellectual property right is granted by this document or in connection with the sale of Quest products. EXCEPT AS SET FORTH IN QUEST'S TERMS AND CONDITIONS AS SPECIFIED IN THE LICENSE AGREEMENT FOR THIS PRODUCT, QUEST ASSUMES NO LIABILITY WHATSOEVER AND DISCLAIMS ANY EXPRESS, IMPLIED OR STATUTORY WARRANTY RELATING TO ITS PRODUCTS INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. IN NO EVENT SHALL QUEST BE LIABLE FOR ANY DIRECT, INDIRECT, CONSEQUENTIAL, PUNITIVE, SPECIAL OR INCIDENTAL DAMAGES (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS, BUSINESS INTERRUPTION OR LOSS OF INFORMATION) ARISING OUT OF THE USE OR INABILITY TO USE THIS DOCUMENT, EVEN IF QUEST HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Quest makes no representations or warranties with respect to the accuracy or completeness of the contents of this document and reserves the right to make changes to specifications and product descriptions at any time without notice. Quest does not make any commitment to update the information contained in this document. If you have any questions regarding your potential use of this material, contact: Quest Software World Headquarters LEGAL Dept 5 Polaris Way Aliso Viejo, CA USA [email protected] Refer to our Web site for regional and international office information. Trademarks Quest, Quest Software, the Quest Software logo, and ActiveRoles are trademarks and registered trademarks of Quest Software, Inc in the United States of America and other countries. For a complete list of Quest Software s trademarks, please see Other trademarks and registered trademarks are property of their respective owners. Third Party Contributions Quest ActiveRoles Server contains some third party components (listed below). Copies of their licenses may be found on our website at COMPONENT LICENSE OR ACKNOWLEDGEMENT.NET logging library 1.0 BSD 4.4 ObjectBuilder Microsoft Corporation. All rights reserved. Prototype Javascript Framework Creative Commons 3.0 Quest ActiveRoles Server - Feature Guide Updated - October 18, 2010 Software Version - 6.7

3 CONTENTS INTENDED AUDIENCE CONVENTIONS ABOUT QUEST SOFTWARE, INC CONTACTING QUEST SOFTWARE CONTACTING QUEST SUPPORT INTRODUCTION NEW FEATURES INCLUDED IN VERSION IMPLEMENTING RULES AND ROLES NEW ATTESTATION CAPABILITIES ENTITLEMENT PROFILE WORKFLOW ACTIVITY EXTENSIONS WORKFLOW ENHANCEMENTS NOTIFICATION AND APPROVAL USING EXCHANGE WEB SERVICES USING ACTIVEROLES SERVER SELF-SERVICE MANAGER ENHANCEMENTS BASED APPROVAL USER MANAGEMENT FOR COMMUNICATIONS SERVER CONFIGURING AND ADMINISTERING ACTIVEROLES SERVER UNMANAGED ACCOUNT DOMAINS SUPPORT FOR MICROSOFT SQL SERVER 2008 R ADVANCED MODE OF SELECT GROUPS PAGE IN SELF-SERVICE MANAGER NEW FEATURES INCLUDED IN VERSION IMPLEMENTING RULES AND ROLES WORKFLOWS POLICY EXTENSIONS WINDOWS POWERSHELL SCRIPTING GROUP DEPROVISIONING NEW ATTESTATION REVIEW CONFIGURATION SETTINGS "POLICIES" NODE IN THE ACTIVEROLES SERVER CONSOLE TREE DELEGATING MAILBOX MANAGEMENT TASKS DELEGATING TASK OF ADDING SELF TO GROUPS A GROUP AS A MANAGER OR OWNER OF ANOTHER GROUP DEPROVISIONING USERS OR GROUPS TO RECYCLE BIN USING ACTIVEROLES SERVER GROUP OWNERS iii

4 Quest ActiveRoles Server GROUP PUBLICATION MEMBERSHIP SELF-MANAGEMENT KEYWORD SEARCH RECYCLE BIN SUPPORT FOR SPECIAL-PURPOSE MAILBOX TYPES SUPPORT FOR EXCHANGE SERVER SEARCH BY MULTIPLE NAMES WHEN SELECTING OBJECTS IN THE WEB INTERFACE71 DOCUMENTING THE REASON FOR A CHANGE REQUEST CONFIGURING AND ADMINISTERING ACTIVEROLES SERVER SUPPORT FOR MICROSOFT SQL SERVER SUPPORT FOR DATABASE MIRRORING ENHANCED SUPPORT FOR EXCHANGE SERVER PRESERVING ACTIVEROLES SERVER DATA ON DELETED OBJECTS DEFAULT RETENTION TIME FOR CHANGE HISTORY INCREASED INSTALLING A SEPARATE MANAGEMENT HISTORY DATABASE SEPARATE LICENSE FOR SELF-SERVICE MANAGER FIPS COMPLIANT ENCRYPTION iv

5 Feature Guide Intended Audience This document has been prepared to assist you in becoming familiar with the Quest ActiveRoles Server. The Feature Guide contains the information required to install and use the Quest ActiveRoles Server. It is intended for network administrators, consultants, analysts, and any other IT professionals using the product. Conventions In order to help you get the most out of this guide, we have used specific formatting conventions. These conventions apply to procedures, icons, keystrokes and cross-references. ELEMENT Select Bolded text Italic text Bold Italic text Blue text CONVENTION This word refers to actions such as choosing or highlighting various interface elements, such as files and radio buttons. Interface elements that appear in Quest Software products, such as menus and commands. Used for comments. Used for emphasis. Indicates a cross-reference. When viewed in Adobe Reader, this format can be used as a hyperlink. Used to highlight additional information pertinent to the process being described. Used to provide Best Practice information. A best practice details the recommended course of action for the best result. Used to highlight processes that should be performed with care. + A plus sign between two keystrokes means that you must press them at the same time. A pipe sign between elements means that you must select the elements in that particular sequence. 5

6 Quest ActiveRoles Server About Quest Software, Inc. Quest Software simplifies and reduces the cost of managing IT for more than 100,000 customers worldwide. Our innovative solutions make solving the toughest IT management problems easier, enabling customers to save time and money across physical, virtual and cloud environments. For more information about Quest go to Contacting Quest Software Mail Web site Quest Software, Inc. World Headquarters 5 Polaris Way Aliso Viejo, CA USA Refer to our Web site for regional and international office information. Contacting Quest Support Quest Support is available to customers who have a trial version of a Quest product or who have purchased a Quest product and have a valid maintenance contract. Quest Support provides unlimited 24x7 access to SupportLink, our self-service portal. Visit SupportLink at From SupportLink, you can do the following: Retrieve thousands of solutions from our online Knowledgebase Download the latest releases and service packs Create, update and review Support cases View the Global Support Guide for a detailed explanation of support programs, online services, contact information, policies and procedures. The guide is available at: Note: This document is only available in English. 6

7 Feature Guide Introduction This document provides an overview of the new features introduced in ActiveRoles Server 6.7, and summarizes the features that were first introduced in ActiveRoles Server 6.5 and inherited by ActiveRoles Server 6.7. Each feature is presented in a separate section containing the following elements: Feature Name The title of the section. Description An explanation of the feature. Instructions on how to find or start using the feature (if applicable). Unless otherwise noted, the instructions assume that you are logged on as an AR Server Admin. By default, an AR Server Admin is any member of the Administrators local group on the computer running the ActiveRoles Server Administration Service. Additionally, you should verify that the ActiveRoles Server console is in Advanced view mode: on the View menu, click Mode, and then click Advanced Mode. 7

8 Quest ActiveRoles Server New Features Included in Version 6.7 This section provides an overview of the new features introduced in ActiveRoles Server 6.7. Implementing Rules and Roles Here you can find an overview of features and enhancements relating to ActiveRoles Server s policies (administrative rules) and delegation model (administrative roles). New Attestation Capabilities ActiveRoles Server s automated attestation capabilities now provide for presenting fine-grained directory data to managers or data owners for certification on the accuracy of the data, and supplying the managers and data owners with the means to review the data, correct inaccuracies, or apply remediation measures such as deprovisioning. Any aspect of directory data could be subject to attestation, including the data specific to user logon accounts, service logon accounts, group memberships, computers, contacts, and other types of directory objects. All data and actions taken on attestation requests are archived for subsequent auditing and reporting purposes. The process of reviewing and certifying objects and data held in the directory is referred to as Attestation Review. With earlier versions of ActiveRoles Server, the only supported scenario of Attestation Review was to verify the membership of particular Windows groups. The latest version of ActiveRoles Server supports the following attestation scenarios: Group owners attest membership of their groups Managers (primary owners) or secondary owners of groups are required to complete an audit of the membership of their groups, to ensure that the list of members in each group is complete and accurate. Periodic reviews of group membership help identify and manage user access rights in order to maintain compliance with security and regulatory requirements. Managers attest user accounts of their subordinates Managers are required to complete an audit of user accounts of their subordinates, to ensure that each user account is needed for business reasons and that certain properties of each user account are current and correct. Periodic reviews of user accounts help authorize and validate user identity information held in the directory. Service owners attest their service accounts Owners of user accounts that are used as service logon accounts are required to complete an audit of those accounts, to ensure that each account is needed for business reasons and that certain properties of each account are current and correct. Periodic reviews of service logon accounts help authorize and validate service identity information held in the directory. Users attest their own accounts (self-attestation) End-users are required to review individual properties of their own user accounts and certify that the properties are current and correct. Having employees regularly attest to the accuracy of their user accounts helps ensure that personnel information in the directory is up-to-date. Managers or object owners attest their objects Managers, primary owners, or secondary owners are required to complete an audit of objects of a particular type, such as User, Group, Computer, or Contact objects. Attestation can only be targeted at a single object type. Attestation can be configured, for example, so that the managers of Contact objects are required to review the contacts and their properties, to ensure that each contact is needed for business reason and the contact information is up-to-date. 8

9 Feature Guide Since it is logon accounts, group memberships, and related access controls that govern access to IT resources, the ability to automate attestation of user accounts, service accounts, and group memberships addresses the need for frequent and timely reviews of user profiles that permit or restrict access to various systems and applications within the enterprise. Automated attestation provides a means to verify access control related data, quickly and periodically, to ensure compliance with relevant business laws and regulations. The managers and owners of resources have the business knowledge to determine who should be given access, and need a way to maintain the appropriate level of access to resources. The attestation capabilities of ActiveRoles Server involve presenting access control related data to resource owners for sing-off on the accuracy of the data. The burden of justifying access rights is thereby shifted from IT staff to business managers and resource owners. In addition to reducing the burden on IT by distributing the management of groups and user profiles, this helps organizations to meet compliance requirements which mandate that the resource owner personally control access to the resource. The key design elements of the Attestation Review feature include: Step-by-step configuration of attestation processes An administrator first chooses the attestation scenario, such as attestation of group memberships, attestation of user or service logon accounts, self-attestation, or attestation of objects of a particular type. The type of objects exposed to attestation is determined by the attestation scenario, and cannot be changed after the configuration has been created. Then, the administrator defines the collection of objects and object properties to be exposed to attestation, and configures other options such as scheduling and notification settings. Multiple configurations can be created and administered using the ActiveRoles Server console. However, each configuration may only have a single type of attestation target objects. Flexible definition of what objects are exposed to attestation A collection of objects can be defined using both static and dynamic methods. Dynamic methods specify rules to include or exclude objects from the collection based on properties of objects. Static methods define invariable lists of objects to be included or excluded from the collection. Ability to start reviews on a scheduled or ad-hoc basis An administrator specifies the date and time that the review is to start and the number of days during which the review is to be finished. A review can be scheduled to start on a specific day of the month on specific months or it can be scheduled to start only once on a specific date. An administrator can also start an ad-hoc review, independent of the existing schedule. Support for parallel multiple reviews Multiple reviews can run concurrently, whether on a scheduled or ad-hoc basis. This makes it possible for reviews based on different configurations to take place parallel at the same time. Notifications regarding attestation-related events notifications are provided in association with various events, such as the start of a review. Thus, the managers or object owners can be notified or reminded that they have to perform a review of the objects for which they are responsible. Web console for performing reviews The managers and object owners use ActiveRoles Server s Web Interface to perform a review. Each reviewer is presented with only the objects for which he or she is responsible. The reviewer can view or modify objects and object properties as needed, and attest (certify) objects. 9

10 Quest ActiveRoles Server Operational reports on reviews that are in progress For an ongoing review, a report is provided, indicating the objects that are attested (certified) along with those that are not and making it possible to view the object properties as of the time of the review. Historical reports on reviews that are completed The data specific to the completed reviews is archived and saved for audit purposes. Reports on that data provide administrators or auditors with the ability to view the objects and object properties that were reviewed and certified along with the property values as of the time of certification. By deploying the automated attestation solution, organizations can achieve major benefits in terms of time and cost saving. Automating the process of attesting to directory data provides a way to expedite audit reviews, making it easier to meet regulatory compliance requirements in a timely manner. To conduct Attestation Review, you must first create at least one configuration. You can create a configuration by using the ActiveRoles Server console: In the console tree, expand Configuration Server Configuration, right-click Attestation Reviews, and select New Attestation Review. To access the Web console for performing reviews, open Internet Explorer and go to the address for ActiveRoles Self-Service Manager. (For example, if ActiveRoles Server s Web Interface is installed on the server named host1.company.com, the address is Then, click My Reviews. For more information about the Attestation Review feature, see the Attestation Review chapter in the ActiveRoles Server Administrator Guide. Entitlement Profile The entitlement profile is a list of entitlements, each of which represents authorization to access, use, or manage a particular information resource. A resource could be a single object in the directory, such as a user, group, contact or computer object, or it could be a server-based resource, such as an Exchange mailbox, user home folder, Web application or network file share. In case of a server-based resource, entitlement normally takes the form of user attributes or stems from membership in a certain group. In case of a directory object, entitlement refers to the manager or owner rights on that object. ActiveRoles Server provides the ability to view the entitlement profile of any given user, both in the ActiveRoles Server console and Web Interface. The entitlement profile is implemented as a configurable report that displays information about resources to which a given user is entitled. Configuration of the entitlement profile specifies what resources are to be listed and what information about each resource is to be displayed in the report. ActiveRoles Server provides effective controls to manage configuration of the entitlement profile. A user s entitlement profile is essentially a list of information resources to which the user is entitled. The resource can be one of the following: A personal resource, such as the user s mailbox, home folder, account enabled for Office Communications Server, or Unix-enabled account. A shared, network-based resource, such as a Web application or network file share, that the user has permission to access. A managed resource, such as a group or distribution list, for which the user is responsible as the manager or owner. 10

11 Feature Guide The way in which a user gets entitled to a given resource depends upon the type of the resource: For a personal resource, entitlement takes the form of certain attributes of the user s account in the directory. For a shared resource, entitlement is granted by adding the user to a certain security group in Active Directory. For a managed resource, entitlement is granted by assigning the manager or owner role for a certain object in Active Directory. The building of a user s entitlement profile is done by applying entitlement rules to the entitlement target objects specific to that user. If a given entitlement target object matches the entitlement rules for a particular resource, then the user is regarded as entitled to the resource and information about that resource appears in the entitlement profile. The entitlement target object can be one of the following: The user s account in Active Directory; this object is used to discover the personal resources to which the user is entitled. An Active Directory group of which the user is a member; this object is used to discover the shared resources to which the user is entitled. An Active Directory object for which the user is assigned as the manager or owner; this object is used to discover the managed resources to which the user is entitled. ActiveRoles Server stores the entitlement rules in configuration objects called entitlement profile specifiers. Each specifier holds information about a single resource, enabling ActiveRoles Server to determine whether a given user is entitled to the resource and, if the user appears to be entitled, what information about that resource to include in the user s entitlement profile. Out of the box, ActiveRoles Server is configured so that a user s entitlement profile displays the user s entitlements to the resources listed in the table that follows. ActiveRoles Server administrators can configure the entitlement profile to display information about additional resources. If a user is not entitled to any resources of a particular type, then the user s entitlement profile does not contain the sections specific to that resource type. For example, if a user does not have an Exchange mailbox, then the user s entitlement profile does not contain information about the user s mailbox. RESOURCE TYPE Exchange Mailbox Home Folder Unix-enabled Account Enabled for Office Communications Server Member of Security Group Access to SharePoint Site Owner of Security Group Owner of Distribution List Owner of Resource Exchange Mailbox Owner of Exchange Contact Owner of Computer Owner of Resource (default) RESOURCE NAME address of mailbox Path and name of home folder User principal name Live communications address Group name Group name Group name Group display name Mailbox display name Contact display name Computer name Managed object s name 11

12 Quest ActiveRoles Server To view a user s entitlement profile in the ActiveRoles Server console: Right-click the user and click Entitlement Profile. To view a user s entitlement profile in the ActiveRoles Server Web Interface: Click the user, and then choose Entitlement Profile from the list of commands. To view your entitlement profile in ActiveRoles Self-Service Manager: Click My Entitlements on the Self-Service Home page. To examine pre-defined entitlement profile specifiers, go to the Configuration/Server Configuration/Entitlement Profile Specifiers/Builtin container in the ActiveRoles Server console. To create a specifier, right-click the Entitlement Profile Specifiers container, and then select New Entitlement Profile Specifier. For more information about the Entitlement Profile feature, see the Entitlement Profile chapter in the ActiveRoles Server Administrator Guide. Workflow Activity Extensions In the previous version of ActiveRoles Server, administrators could configure workflow activities of only pre-defined types. The list of activities in the Workflow Designer was restricted to the activity types available out of the box, such as Approval Activity or Notification Activity. There was no way to extend the list by adding new types of activity. Each activity type determines a certain workflow action (for example, originating an approval task or notification) together with a collection of activity parameters to configure the workflow action (for example, parameters that specify the approvers or notification recipients). ActiveRoles Server builds upon this concept, providing the ability to implement and deploy custom types of workflow activity. It enables custom activity types to be created as necessary, and listed in the Workflow Designer along with the pre-defined activity types, allowing administrators to configure workflow activities that perform custom actions determined by those new types of workflow activity. ActiveRoles Server allows the creation of custom activities based on the Script Activity built-in activity type. However, creating and configuring a script activity from scratch can be time-consuming. Custom activity types provide a way to mitigate this overhead. Once a custom activity type is deployed that points to a particular script, administrators can easily configure and apply workflow activities of that type, having those activities perform the actions determined by the script. The activity script also defines the activity parameters specific to the activity type. Custom activity types provide an extensible mechanism for deploying custom workflow activities. This capability is implemented by using the Policy Type object class. Policy Type objects can be created by using the ActiveRoles Server console, with each object representing a certain type of custom workflow activity. 12

13 Feature Guide Design Elements The extensibility of workflow activity types is designed around two interactions: activity type deployment and activity type usage. Activity Type Deployment The deployment process involves the development of a script that implements the workflow action and declares the activity parameters; the creation of a Script Module containing that script; and the creation a Policy Type object referring to that Script Module. To deploy an activity type to a different environment, you can export the activity type to an export file in the source environment and then import the file in the destination environment. Using export files makes it easy to distribute custom activity types. Activity Type Usage This is the process of configuring workflow activities. It occurs whenever you add an activity to a workflow in the Workflow Designer. To add an activity to a workflow, you drag the desired activity type from the toolbox onto the workflow process diagram. The toolbox, located on the left of the diagram, lists all the activity types defined in ActiveRoles Server, including the custom activity types. For each activity of a custom type the Workflow Designer provides a page for configuring the activity parameters specific to that activity type. Once the activity parameters have been configured, the workflow contains a fully functional activity of the selected custom type. ActiveRoles Server provides a graphical user interface, complete with a programming interface, for creating and managing custom activity types. Using those interfaces, ActiveRoles Server workflows can be extended to meet the needs of a particular environment. ActiveRoles Server also has a deployment mechanism by which administrators put new types of workflow activity into operation. Since workflow activity extension involves two interactions, ActiveRoles Server provides solutions in both areas. The Administration Service maintains activity type definitions, exposing activity types to its clients such as the ActiveRoles Server console or ADSI Provider. The console can be used to: Create a new custom activity type, either from scratch or by importing an activity type that was exported from another environment. Make changes to the definition of an existing custom activity type. Add an activity of a particular custom type to a workflow, making the necessary changes to the activity parameters provided for by the activity type definition. Normally, an ActiveRoles Server expert develops a custom activity type in a separate environment, and then exports the activity type to an export file. An ActiveRoles Server administrator deploys the activity type in the production environment by importing the export file. After that, the Workflow Designer can be used to configure and apply activities of the new type. Use the ActiveRoles Server console to create a custom activity type: 1. In the console tree, expand Configuration Server Configuration, right-click Policy Types, and select New Policy Type. 2. In the New Object - Policy Type wizard, type a name, a display name and, optionally, a description for the new Policy Type object. The display name is used to identify the activity type in the Workflow Designer. This name is displayed in the activities toolbox located on the left of the workflow process diagram. 13

14 Quest ActiveRoles Server 3. Click Next. 4. Click Browse and select the Script Module containing the script that will be used by the activities of this type. The Script Module must exist under the Configuration/Script Modules container and hold a policy script. For information about policy scripts, see the ActiveRoles Server SDK documentation. 5. In the Policy Type category area, click Workflow activity. 6. From the Function to run list, select the name of the script function that will be run by the activities of this type. The list contains the names of all the functions found in the script you selected in Step 4. Every activity of this type will run the function you select from the Function to run list. 7. From the Function to declare parameters list, select the name of the script function that defines the parameters specific to this type of workflow activity The list contains the names of all the functions found in the script you selected in Step 4. Every activity of this type will have the parameters that are specified by the function you select from the Function to declare parameters list. Normally, this is a function named oninit (see the ActiveRoles Server SDK for details). 8. Click Next and follow the steps in the wizard to complete the creation of the new Policy Type object. Use the Workflow Designer to view the custom activity type you have created, and to configure a workflow activity of that type: 1. In the ActiveRoles Server console tree, expand Configuration Policies Workflow, and select the workflow to which you want to add an activity. This opens the Workflow Designer window in the details pane, representing the workflow definition as a process diagram. 2. In the activities toolbox, on the left of the workflow process diagram, observe the display name of the custom activity type this is the display name you specified when creating the Policy Type object. 3. Drag your custom activity type onto the process diagram, to add an activity of that type to the workflow. 4. Right-click the activity you have added, and click Properties. 5. In the Properties dialog box, view or change the name and description of the activity. By default, the name and description of the activity are the same as the display name and description of the Policy Type object. 6. If any parameters are declared in the activity type, use the Properties dialog box to view or change parameter values: click the name of a parameter in parameters list, and then click Edit. 14

15 Feature Guide Workflow Enhancements The workflow capabilities of ActiveRoles Server have been extended to provide new options for configuring workflow start conditions, approval rules, and notification recipients. Changes to group membership as a workflow start option Workflow start conditions can be configured so that only a request to add or remove a member from a group would cause the workflow to start. This enables group membership changes to be expressly made subject to approval. The user interface for setting up workflow start conditions, on the Select Operation page for the Group object type, provides the Change membership option along with the following choices: Add member to group Causes the workflow to start once the addition of members to the group has been requested. Remove member from group Causes the workflow to start once the removal of members from the group has been requested. An approval workflow with the Add member to group or Remove member from group start option would ensure that the addition or removal of group members occurs only after this is approved by the designated person (approver). The user interface for configuring workflow start conditions also provides new, group membership related options to set up filtering criteria on operation requests. Filtering criteria can be based on properties of: Added member The workflow starts if certain properties of the object being added to the group meet certain conditions. This could be used, for example, to require approval when users from a particular department are going to be added to the group. Removed member The workflow starts if certain properties of the object being removed from the group meet certain conditions. This could be used, for example, to require approval when a user with a particular job title or role (say, manager) is going to be removed the group. Manager of a group member as an approver Approver can be assigned to approval task based on the Manager property of the user of which the addition to, or removal from, a group has been requested. This option makes it possible for an approval rule to require the approval of the user s manager whenever that user is going to be added or removed from a group. New options for selecting notification recipients The notification recipient options have been extended to include the following choices, which apply to workflows that control changes to group membership: Person being added or removed from a group Manager of person being added or removed from a group With the first option, a workflow can be configured to send a notification to the person that is going to be added to, or removed from, a group. For example, when processing an approval-dependent request to add a user to a group, the workflow could notify the user of whether the request has been approved or rejected. The workflow could also notify the user about the completion of the request, informing that the user has become a member of the group. 15

16 Quest ActiveRoles Server With the second option, a workflow can be configured to notify the manager of the person that is going to be added to, or removed from, a group. This, for example, could be a notification of the fact that someone has submitted an approval-dependent request to change the group memberships of a direct report of the manager s, or a notification informing that a direct report has been added or removed from a particular group. Cc and Bcc notification recipients The notification recipient options have been enhanced to allow for carbon copy (Cc) and blind carbon copy (Bcc) notification recipients. The recipient choices that are available for the primary (To) recipients are also available for both the Cc and Bcc recipients. For example, notification of approval tasks can be configured so that the approver is the primary recipient of the notification message whereas the other interested parties are carbon copy recipients. Configurable tokens for lists of objects In notification message templates, tokens can be used to add information about objects involved in the workflow process at run time. For example, given an approval-dependent request to add certain objects to a group, a workflow could generate a notification message that contains a list of those objects. This is accomplished by using the Requested Property Change token, with the Members property selected to examine. The resulting message includes a list of items each of which has a number of fields populated with certain properties of the corresponding object. What object properties are to be shown in the list depends upon the configuration of the token. When you choose to add the Requested Property Change token to a notification message template, you are first prompted to select a property whose values will be substituted for the token at run time. If you select a property that specifies a list of member objects (for example, the Members, Member Of or Managed By property), then you have additional configuration options. You can configure the token to show the desired properties in the list of objects. The following options are available: Name For each member object, the token only shows the object s display name. If the display name is not set on a member object, the name of the object is shown instead. Distinguished Name (DN) For each member object, the token shows the distinguished name of the object. The distinguished name identifies the full path to the object, including the name of the object and the names of all parent objects to the root of the domain. Selected properties For each member object, the token shows a number of properties, allowing you to select the properties you want. By default, the token shows only the display name. You can add other properties to the list as needed. You can also configure the order of the fields in the resulting list of objects by moving properties up and down: moving a property up moves the corresponding field to the left. First, use the ActiveRoles Server console to create a new workflow definition with the appropriate start options: 1. In the console tree, select Configuration Policies Workflow, right-click in the details pane, and then select New Workflow Policy. 2. Complete the New Object - Workflow Definition wizard to create the workflow definition. 3. Double-click the name of the newly created workflow definition in the details pane. 4. In the details pane, click the link named Click to view or modify workflow start conditions. 5. On the Workflow Start Conditions page, click the Select Operation button. 16

17 Feature Guide 6. On the Select Operation page, select Group from the Target object type list, click the Change membership option, select the check boxes beneath that option, and then click Finish. 7. Examine the new options for filtering: a) On the Workflow Start Conditions page, click the Configure Filtering button. b) On the Configure Filtering page, click the Add button and then click Added Member or Removed Member. You can use the Configure Condition dialog box to set up a condition based on a property of objects being added or removed from a group. c) Click Cancel to close both the Configure Condition dialog box and Configure Filtering page. 8. Click OK to close the Workflow Start Conditions page, and then click Save Changes in the Workflow Designer. Next, configure an approval workflow in which the manager of a group member would act as an approver for the operation of adding or removing the member from a group: 9. Drag Approval Activity onto the upper part of the workflow process diagram in the Workflow Designer, to add an Approval Rule item to the workflow definition. 10. Double-click the approval rule you have added on the workflow process diagram, to open the Approval Activity Properties page. 11. Click the Approvers tab on the Approval Activity Properties page, and then click the Designate Approvers button. 12. On the Designate Approvers page, select the check box named Manager of person being added or removed from target group, and then click OK. Next, examine the new options for selecting notification recipients: 13. Click the Notification tab on the Approval Activity Properties page, and then click the Add button under Events, Recipients and Messages to open the Notification Settings dialog box. 14. In the Notification Settings dialog box, observe the following new options: The check boxes in the Group member area The Cc Recipients and Bcc Recipients buttons Clicking the Cc Recipients or Bcc Recipients button opens a dialog box where you can select carbon copy or blind carbon copy notification recipients. Examine the new options for configuring a token in a notification message template: 15. Click the Notification Message tab in the Notification Settings dialog box, and then click the Modify button to open the Configure Notification Message page. 16. On the Configure Notification Message page, in the text editor position the cursor where you want to insert a token, and then click the Insert Token button. For example, you might position the cursor right after the <body> tag, to insert a token at the beginning of the message body. 17. In the Insert Token dialog box, select the Requested Property Change token, and then click OK. 17

18 Quest ActiveRoles Server 18. In the Select Object Property dialog box, click Members in the list of object properties, and then click OK. 19. On the Choose Properties to Display page, observe the options that control the contents of the list of members to be displayed in the notification messages. You can configure the list to contain only the name or distinguished name for each member, or you can choose other properties to include in the list. Notification and Approval Using Exchange Web Services ActiveRoles Server can use Exchange Web Services (rather than SMTP server) to communicate with Exchange Server when sending notification messages and getting response to notification messages. This enables notification recipients to perform approval tasks by replying to notification messages from their regular clients, instead of using the Web Interface pages to approve or reject the requests. Thus, with the use of Exchange Web Services, ActiveRoles Server makes it possible for an approval workflow to behave as follows: A change request that requires approval causes ActiveRoles Server to send a notification message to the designated approver, with the message body containing the option to approve or reject the request. The approver replies to the notification message by choosing the desired option (either approve or reject) and typing in a text to explain the reason for that choice. ActiveRoles Server receives the reply message from the approver, checks to see if the approver elected to approve or reject the request, and then allows or denies the requested changes accordingly. The use of Exchange Web Services calls for the following prerequisites: Exchange 2007 or 2010 in your Exchange organization. Exchange Web Services is deployed with the Client Access server role. Dedicated mailbox hosted on an Exchange 2007 or 2010 server. The mailbox should be reserved for the exclusive use of ActiveRoles Server. Configuration settings The following configuration settings are available with the Exchange Web Services option for transport. Exchange Web Services address This setting identifies the URL of the Exchange Web Services endpoint, which locates the exchange.asmx file on the Exchange server running the Client Access server role. For example, ActiveRoles Server s mailbox credentials This setting specifies the user name and password of the mailbox through which ActiveRoles Server will send and receive . The mailbox should be located on an Exchange 2007 or Exchange 2010 based mailbox server, and should be reserved for the exclusive use of ActiveRoles Server. It is important that no applications other than ActiveRoles Server access this mailbox. Processing messages in ActiveRoles Server s mailbox by other applications, such as Office Outlook, can cause an adverse effect on the functionality of ActiveRoles Server. 18

19 Feature Guide Options for the Approve and Reject links This setting controls the behavior of the Approve and Reject links in the notification messages delivered using this configuration. Two options are available: Send approval response by Approve or reject via Web Interface If Send approval response by is selected, notification recipients can perform approval tasks from within their application. When an approver chooses one of the links provided in a notification message to approve or reject a request, the application replies with an message containing information about the approval decision. ActiveRoles Server receives the reply message, checks it to see if the approver elected to approve or reject the request, and then allows or denies the requested changes accordingly. If Approve or reject via Web Interface is selected, choosing the Approve or Reject link in a notification message directs the application to open a Web Interface page for performing the approval task. The page may not open as expected if the application does not support HTML format or an appropriate Web browser does not exist on the device running the application. Perform the following steps in the ActiveRoles Server console to configure the default mail settings with the option to use Exchange Web Services: 1. In the console tree, select Configuration Server Configuration Mail Configuration. 2. In the details pane, double-click Default Mail Settings. 3. In the Default Mail Settings Properties dialog box, configure the settings on the Mail Setup tab: a) From the Settings for list, select Exchange Web Services. b) In the Exchange Web Services address box, supply the URL of the Exchange Web Services endpoint. This URL locates the exchange.asmx file on the Exchange server that is running the Client Access server role. For example, c) Under Mailbox credentials, supply the user name and password of the mailbox through which ActiveRoles Server will send and receive . Create a mailbox on an Exchange 2007 or 2010 mailbox server for the exclusive use of ActiveRoles Server, and supply user name and password of the mailbox user. d) Verify the settings you have configured. Click Verify Settings, supply a valid address, and then click Send. This causes ActiveRoles Server to send a diagnostic message to the address you supplied. The message is attempted to be delivered from ActiveRoles Server s mailbox by using Exchange Web Services. You can check the mailbox with the address you supplied to see if the diagnostic message has been received. 4. Verify that the Send approval response by option is selected on the Mail Setup tab. 5. When finished, click OK to close the Default Mail Settings Properties dialog box. 19

20 Quest ActiveRoles Server Using ActiveRoles Server This section summarizes the features and enhancements that improve the user experience of those who use ActiveRoles Server to perform day-to-day administrative tasks. Self-Service Manager Enhancements ActiveRoles Self-Service Manager included with the new release of ActiveRoles Server offers a number of enhancements that will help self-service users to locate, select and join published groups and distribution lists. Improved ease of use for joining groups The Self-Service Manager Home page has been redesigned to provide a separate command Request Access making it easier for users to discover the self-service capability that allows them to join published groups and distribution lists. The Request Access command brings you directly to a page where you can select the groups or distribution lists you want to join. Consequently, the My Access page has been updated to remove the function of joining groups, and is now intended only to view or leave the groups and distribution lists in which you have membership. You can navigate to the My Access page from the Request Access page as well as from the Self-Service Manager Home page. The Request Access page provides an easy-to-use facility for selecting groups and distribution lists the Select Groups dialog box. The dialog box lists the groups that are published to Self-Service Manager, and provides the capability to find a group by name, display name and keywords, as well as to sort columns, filter on column data, and page through the list of groups. Display name to identify groups In the lists of groups each group is now identified by the display name (rather than by the name) of the group. By supplying meaningful display names, group owners and IT administrators could help self-service users to discover the desired groups. In contrast, group names might be cryptic due to rigid naming rules adopted in many organizations. The display name for a group can be supplied using the ActiveRoles Server console or Web Interface. In the console, you can view or change the display name from the General tab in the Properties dialog box for a group. In the Web Interface, the display name can be found on the General tab of the General Properties page for a group. Since display name of groups is widely used in Self-Service Manager, ActiveRoles Server does not allow a group to be published if the group does not have a display name. In both the ActiveRoles Server console and Web Interface, the Publish Group to Self-Service Manager page provides the option to view, supply or change the display name of the group that is going to be published. Resource address to help distinguish groups ActiveRoles Server introduces a new property of groups resource address (URL) to help self-service users verify the resource that the group members are permitted to access. If a particular group is used to control access to a certain resource, such as a Web application or a network file share, this property can be used to supply the address (URL) of the Web-based resource or the path to the network resource. The resource address information could help identify the purpose of the group. 20

21 Feature Guide The users that have read and write access to the Resource Address (URL) attribute can view or change the resource address setting by using the ActiveRoles Server console or Web Interface. In the console, the resource address assigned to a group can be administered on the General tab in the Properties dialog box for that group. In the Web Interface, the resource address setting is available on the on the General tab of the General Properties page for a group. The group lists offered by Self-Service Manager display the resource address in a separate column. For every group that has a resource address specified a Web link is provided in the Resource Address (URL) column so that self-service users could quickly verify the resource by clicking the link. First, publish a group to Self-Service Manager. In the ActiveRoles Server console, right-click the group, click Publish, and then perform the following steps in the Publish Group to Self-Service Manager dialog box: 1. In the Display name box, verify that a display name is supplied for the group. If you attempt to publish a group that does not have a display name, you will be prompted to supply a display name. 2. In the Resource URL box, type a valid Web address, assuming that the group has access rights to the Web-based resource identified by that address. For test purposes you may supply any valid Web address (for example, the address of your SharePoint Portal site). To verify the address you have supplied, click the button next to the Resource URL box. This will open the resource located by that address in your Web browser. 3. Click the Publish button. Then, use Self-Service Manager to join the group you have published. 1. On the Self-Service Manager Home, click Request Access. 2. On the Request Access page, click the Select Groups button. 3. In the Select Groups dialog box, observe the group you published: The display name and the resource address for the group is displayed in the corresponding list columns. 4. Click anywhere in the list row representing the group, and then click OK. The Request Access page will inform you of whether your request to join the group has succeeded. Quick link to join groups ActiveRoles Self-Service Manager now provides the option for a user to request self-membership in a group by clicking a single Web link (for example, a link that would come with an message). The link is available on the General Properties page for every group in Self-Service Manager. A group owner can copy the link to the Clipboard and then paste it into an message, so that the recipients of the message could submit a request to join the group by clicking the link in the message. First, use Self-Service Manager to take over a certain group, assigning yourself to the primary owner (manager) role for that group: 1. On the Self-Service Home page, in the My Groups box, point to Tasks and then click Claim a group. 2. On the Claim a Group page, click the Add button. 21

22 Quest ActiveRoles Server 3. Use the Select Object dialog box to find and select the desired group. 4. Verify that the Assign me to the owner role option is selected on the Claim a Group page, and then click Save. Then, navigate to the My Groups page and examine the group you have claimed: 1. On the Navigation Bar, point to Self-Service, and then click My Groups. 2. In the list of groups on the My Groups page, click the name of the group. 3. On the Members page, examine the list of the group members to ensure that you are not a member of that group. You should not be a group member; otherwise, your request to join the group will be disregarded so the link to join the group will have no effect. 4. In the Command Menu area, click General Properties. 5. Observe the Link to join this group field at the bottom of the General tab. 6. Click the button next to the Link to join this group field, to copy the link to the Clipboard. Now you can see the link in action: Start a new instance of your Web browser, paste the contents of the Clipboard into the address box, and then press ENTER. This will open the Request Access page, informing of the success of your request to join the group. You can use the Members page you opened from the My Groups page to verify that your user account has been added to the group. Based Approval In addition to the Web Interface pages for performing approval tasks, ActiveRoles Server provides the facility to approve or reject a pending request by replying to a notification message that informs of the request. An approval workflow can be configured to behave as follows: Upon the receipt of a change request that requires approval, ActiveRoles Server sends a notification message to the designated approvers, with the message body containing the option to approve or reject the request. The approver replies to the notification message, choosing the desired option approve or reject. In the reply message the approver is expected to provide a comment explaining the reason for that choice. ActiveRoles Server receives the reply massage from the approver, checks to see if the approver elected to approve or reject the request, and then allows or denies the requested changes accordingly. This way the capabilities to work with approval requests are integrated into the client. The approvers do not need a Web browser to view, and respond to, their approval requests. This, for instance, enables Microsoft Office Outlook users to manage approvals even when they are offline. One more opportunity is to manage approvals using an client on a mobile device. 22

23 Feature Guide Integration with Microsoft Office Outlook For organizations that have deployed Microsoft Exchange Server 2007 or 2010, and use Microsoft Office Outlook 2007 or 2010 as their standard client, ActiveRoles Server provides an approval management facility integrated in Outlook. This enables Microsoft Office end-users to manage approvals in ActiveRoles Server through the application they use on a day-to-day basis. The Add-in for Outlook component that is included with ActiveRoles Server offers the basic functionality for processing and submitting approvals. ActiveRoles Server Add-in for Outlook allows Microsoft Outlook users to approve or reject requests that are sent to them for approval. Requests are delivered through notification messages, and can be approved or rejected directly from the notification message, without having to use ActiveRoles Server's Web Interface pages. In every message from ActiveRoles Server that notifies of an approval request, ActiveRoles Server Add-in for Outlook adds the Approve and Reject buttons along with Approve and Reject menu commands allowing the approver to respond by selecting the appropriate button or command. Software and configuration requirements Integration with Microsoft Office Outlook has the following software and configuration prerequisites: Microsoft Exchange Server 2007 or 2010 Integration with Outlook requires at least one server running Exchange 2007 or 2010 that holds the Client Access server role and Mailbox server role, to be deployed in your Exchange organization. Microsoft Office Outlook 2007 or 2010 The approvers use Outlook 2007 or 2010 as their client application. ActiveRoles Server Add-in for Outlook The Add-in for Outlook component of ActiveRoles Server is installed on the computer running Microsoft Office Outlook. The software requirements specific to ActiveRoles Server Add-in for Outlook are listed in the ActiveRoles Server Release Notes. Approvers mailboxes The mailboxes where approval and rejection takes place are on a Mailbox server running Exchange 2007 or Although not mandatory, this condition is highly advisable. ActiveRoles Server s mailbox A mailbox reserved for the exclusive use of ActiveRoles Server. This mailbox should be on a Mailbox server running Exchange 2007 or Exchange Web Services The approval workflow has the approval rule notification settings configured so that ActiveRoles Server uses Exchange Web Services to communicate with Exchange. These settings include the address (URL) of the Exchange Web Services endpoint on an Exchange 2007 or 2010 server that holds the Client Access server role, along with the credentials that identify ActiveRoles Server s mailbox. Approval using clients other than Outlook For organizations that have deployed Microsoft Exchange Server 2007 or 2010, but use an client application other than Outlook 2007 or 2010, ActiveRoles Server offers the ability to approve or reject change requests by simply replying to notification messages that inform approvers of approval tasks. In this case, the notification message contains selectable options that, when clicked or tapped, cause the application to create a new message in reply to the notification message. The reply message contains indication of the approval decision (approve or reject) and prompts the approver to supply a comment on the approval decision (approval or rejection reason). Then, the approver sends the reply message, thereby completing the approval task. 23

24 Quest ActiveRoles Server Software and configuration requirements The ability to manage approvals from non-outlook clients calls for the same software and configuration prerequisites as Outlook integration, with the following exceptions and additions: The client applications that can be used to manage approvals are not restricted to Microsoft Office Outlook 2007 or It is possible to use, for instance, earlier Outlook versions or applications on mobile devices. ActiveRoles Server Add-in for Outlook does not need to be installed on the computer running the client application. The approval rule notification settings is configured so that the notification messages originated by ActiveRoles Server have integration with the Web Interface turned off. Ensure that the Send approval response by option is selected in the properties of the configuration that is used by the approval rule (this is the default setting). First, use the ActiveRoles Server console to configure an approval workflow as follows. 1. In the console tree, select Configuration Policies Workflow Builtin Approval by Primary Owner (Manager). This will display the workflow process diagram in the Workflow Designer, in the details pane. 2. In the workflow process diagram, double-click Approval Rule. 3. On the Approval Activity Properties page, click the Notification tab. 4. On the Notification tab, under Events, Recipients and Messages, click the Add button. 5. In the Notification Settings dialog box, do the following: a) Click Task created in the Select an event list. b) On the Notification Recipients tab, in the Approver area, select the check box named Persons who are responsible for operation approval (Approvers). c) Click OK. 6. On the Notification tab, under Server Settings, click the Properties button. 7. On the Mail Setup tab in the Properties dialog box for mail settings, do the following: a) Select Exchange Web Services from the Settings for list. b) In the Exchange Web Services address box, supply the URL of the Exchange Web Services endpoint. This URL locates the exchange.asmx file on the Exchange server that is running the Client Access server role. For example, c) Under Mailbox credentials, supply the user name and password of the mailbox through which ActiveRoles Server will send and receive . Create a mailbox on an Exchange 2007 or 2010 mailbox server for the exclusive use of ActiveRoles Server, and supply user name and password of the mailbox user. d) Click Verify Settings to check the Exchange Web Services and ActiveRoles Server s mailbox settings. e) Verify that the Send approval response by option is selected. f) Click OK to close the dialog box. 8. Click OK to close the Approval Activity Properties page. 9. Click the Save Changes button in the Workflow Designer. 24

25 Feature Guide Next, install ActiveRoles Server Add-in for Outlook on the computer that will be used by the approver: 1. In the ActiveRoles Server DVD Autorun window, go to the ActiveRoles Server page. 2. On the ActiveRoles Server page, click either Add-in for Outlook (x86) or Add-in for Outlook (x64), depending on whether the 32-bit or 64-bit edition of Microsoft Office Outlook is installed on the computer. With a 64-bit edition of Outlook, choose Add-in for Outlook (x64); otherwise, choose Add-in for Outlook (x86). 3. Follow the instructions in the Setup wizard to install the add-in. Next, configure the following objects in your Active Directory environment, for the purposes of a demonstration scenario: Test group Create a group in Active Directory. The changes to the members list of this group will be subject to approval. Configure self-service Publish the test group to Self-Service Manager so that changes to the members list require approval from the manager of the group. This can be done by using the Publish command on that group in the ActiveRoles Server console. On the Publish Group to Self-Service Manager page, under Changes to this group require, select the Approval by the primary owner (manager) of the group check box. Test user Create a test user account in Active Directory. This user will use Self-Service Manager to join the test group. Approver Create a mailbox-enabled user account for the approver. Ensure that the mailbox is on a mailbox server running Exchange 2007 or The approver will use Outlook to approve or reject changes to the members list of the test group. Manager of the test group Assign the approver to the manager (primary owner) role for the test group. This can be done from the Managed By page, by selecting the approver s account as the manager for that group. Security settings Give the test use the permission to join or leave the test group: Apply the Self-Service - My Memberships Management Access Template to the Published Groups Managed Unit, selecting the test user account as the Trustee. Ensure that the test user is not an AR Server Admin (the requests originated by an AR Server Admin bypass approval in ActiveRoles Server). The Self-Service - My Memberships Management Access Template is in the folder Configuration/Access Templates/Self-Service Manager. The Published Groups Managed Unit is in the folder Configuration/Managed Units/Builtin. Now you can walk through a demonstration to see approval management in action: 1. Log on as the test user and use Self-Service Manager to submit a request to join the test group: a) On the Self-Service Home page, click Request Access. b) On the Request Access page, click Select Groups. c) In the Select Groups dialog box, click the display name of the test group, and then click OK. 2. Log on as the approver and check the Inbox in Outlook for the notification message from ActiveRoles Server. 3. Right-click the notification message, and then click Approve. This will create and open a reply message in Outlook. 25

26 Quest ActiveRoles Server 4. Optionally, type an approval reason in the reply message; then, send the message. 5. Verify that the test user has been added to the test group (for example, by inspecting the Members list of the test group in the ActiveRoles Server console). If you use an application other than Outlook to access the approver s Inbox, whether on a desktop or mobile device, then you can approve or reject the request by clicking or tapping the corresponding link in the notification message. Thus, to approve the request, click or tap the Approve this request link to have the application create a reply message. Type your approval reason in the reply message and then send that message. Do not alter the subject of the reply message since the subject line contains information needed by ActiveRoles Server to identify and handle the approval request. User Management for Communications Server The ActiveRoles Server console can be used to enable and configure domain user accounts for Microsoft Office Communications Server 2007 or 2007 R2, provided that ActiveRoles Server Support Pack for OCS is deployed in the ActiveRoles Server environment. Support Pack for OCS is an optional add-on module that is included on the ActiveRoles Server distribution media and can be used at no additional cost. In the wizard for creating user accounts, the ActiveRoles Server console offers a page where you can choose the option to enable the newly created user account for Communications Server. To enable or disable an existing user account for Communications Server, you can use the Communications Server tab in the Properties dialog box for that user account. The additional wizard page along with the Communications Server tab appears in the console when ActiveRoles Server Support Pack for Office Communications Server is installed along with Microsoft Office Communications Server 2007 or 2007 R2. The wizard page that is used to enable a user account for Communications Server provides for the following settings: Enable user for Office Communications Server By selecting this check box you enable the user for Office Communications Server. Sign-in name This setting specifies the SIP (Session Initiation Protocol) address to be registered for this user and will be used to route messages to and from the user. The sign-in name is in the form "sip:user@domain" and must be unique. Server or pool This setting identifies the Standard Edition server or Enterprise pool with which this user will be registered. From the Communications Server tab you can configure the following settings: Enable user for Office Communications Server Indicates whether the use account is enabled for Communications Server. To disable the user account for Communications Server, clear this check box. To re-enable the user, select this check box. Sign-in name This setting identifies the SIP (Session Initiation Protocol) address that is currently registered for the user and is used to route messages to and from the user. The sign-in name is in the form "sip:user@domain" and must be unique. Server or pool This setting identifies the Standard Edition server or Enterprise pool with which the user is registered. Allow anonymous participants Select this check box to allow the user to invite anonymous participants to meetings. An anonymous participant is an external user who does not have an Active Directory identity and who is not federated with your organization. 26

27 Feature Guide Enable Enterprise Voice A user enabled for Enterprise Voice routing relies on the Office Communications Server infrastructure to route calls both to and from the user. The user can make and receive calls using Communicator, Communicator Phone Edition, or some SIP phone device. Enable Enterprise Voice and PBX integration A user who is enabled with PBX integration can make and receive calls using both a legacy PBX desktop phone and an Enterprise Voice client. All calls that are sent to a user ring all SIP endpoints and phones registered to that user. This option also enables the user for Enterprise Voice routing. Enable PC-to-PC communication only With this option, the user can make PC-to-PC audio calls but is not enabled for remote call control or Enterprise Voice. Enable Remote call control A user enabled for remote call control can use Microsoft Office Communicator to control his desktop phones. The user can control his desktop phone line from Microsoft Office Communicator to make PC-to-PC calls and PC-to-phone calls. Server URI This is the URI of the Remote Call Control server, used for remote call control and PBX integration. The server URI must be specified as a valid 'sip:' URI, such as 'sip:endpoint@domain'. Line URI This is the URI of the user s phone, used for remote call control and Enterprise Voice routing. The line URI must be specified as a valid 'sip:' or 'tel:' URI, such as 'tel: '. Enable federation Select this check box to allow the user to communicate with users in another organization over a federated partner connection. Enable remote user access Select this check box to allow the user, when outside your network, to connect through an edge server to Office Communications Server. Enable public IM connectivity Select this check box to allow the user to communicate with users of public IM networks. Archive internal IM conversations Select this check box to archive the internal IM conversations in which the user participates. This setting requires the Archive according to user settings option for internal IM conversations to be selected in Office Communications Server at the forest level. Archive federated IM conversations Select this check box to archive the federated IM conversations in which the user participates. This setting requires the Archive according to user settings option for federated IM conversations to be selected in Office Communications Server at the forest level. Enable enhanced presence Select this check box to enable the user to control their presence with more granularity. Enhanced presence enables users to create different presence categories and assign data items to the categories. Different views on the categories can be created. With enhanced presence, users can expose different presence states for different categories of contacts Ensure that Microsoft Office Communications Server 2007 or 2007 R2 is deployed in the domain that is registered for management with ActiveRoles Server, and then install ActiveRoles Server Support Pack for Microsoft Office Communications Server. You can install this software from the ActiveRoles Server distribution media, by clicking ActiveRoles Server Support Pack for OCS on the Solutions page in the ActiveRoles Server DVD Autorun window. Installation of the Support Pack must be performed on the computer running the ActiveRoles Server Administration Service. 27

28 Quest ActiveRoles Server Once you have installed Support Pack for OCS, you can use the ActiveRoles Server console to configure a user account for Communications Server: 1. Right-click an organizational unit, and select New User. 2. Follow the steps in the New Object - User wizard until you reach the page containing the Enable user for Office Communications Server check box. 3. Select the Enable user for Office Communications Server check box, supply a sign-in name, and choose the appropriate Standard Edition server or Enterprise pool. 4. Follow the wizard steps to create the new user account. 5. Double-click the user account you have created, and go to the Communications Server tab in the Properties dialog box to view or change the Communications Server related settings. 28

29 Feature Guide Configuring and Administering ActiveRoles Server This section summarizes the features and enhancements that improve the user experience of those who manage ActiveRoles Server, implementing and maintaining the ActiveRoles Server-based administrative structure. Unmanaged Account Domains When registering an Active Directory domain, ActiveRoles Server provides the option to use the domain as an unmanaged domain. With this option you can register a domain without incurring the full cost of licensing the user accounts in that domain for management by ActiveRoles Server. An unmanaged domain is basically a domain that is registered with ActiveRoles Server for read-only access. The use of the unmanaged domain option allows you to reduce licensing costs since the user count that corresponds to the unmanaged domains is not added to the total licensed user count. The only requirement is that each unmanaged domain should not contain more users than indicated in the license for ActiveRoles Server or ActiveRoles Self-Service Manager. This allows you to have any number of unmanaged domains, each containing as many users as indicated in your license. Before the release of ActiveRoles Server 6.7, if you only needed ActiveRoles Server to list and select user accounts from a particular domain, you had to register that domain with ActiveRoles Server as a regular managed domain. Since each enabled user account in the regular managed domains must have a separate license, registering an additional domain thus required an ActiveRoles Server license with the licensed user count that is greater than the total of the enabled user accounts in the present managed domains plus the number of the enabled user accounts in the domain being added. This means that you need to purchase additional user licenses for ActiveRoles Server even though you will not use ActiveRoles Server for user management in the domain you are going to register. ActiveRoles Server addresses the problem by allowing you to register unmanaged domains. With the use of the unmanaged domain option, ActiveRoles Server makes it possible to reduce licensing costs in the following scenarios: Group membership management When used to add members to a group, by selecting the new members from a list of objects, ActiveRoles Server requires the domain that holds the objects to be registered. If you only use ActiveRoles Server for selecting member objects when managing group membership, you can register the domain that holds the member objects as an unmanaged domain. Exchange resource forest When used to provision Exchange mailboxes in a forest that is different from the forest that holds the accounts of the mailbox users, ActiveRoles Server requires the domain of the mailbox users (account domain) to be registered. If you do not use ActiveRoles Server for user management in the account domain, you can register that domain as an unmanaged domain. As applied to a registered unmanaged domain, the features and functions of ActiveRoles Server are limited to those that do not require write access to the objects held in that domain (including write access to the object data that is stored by ActiveRoles Server as virtual attributes). Thus, you can use ActiveRoles Server to: Search for, list and select objects from unmanaged domains Populate groups in regular managed domains with objects from unmanaged domains Retrieve and view properties of objects held in unmanaged domains 29

30 Quest ActiveRoles Server Assign users or groups from unmanaged domains to the role of manager, primary owner, or secondary owner for objects held in regular managed domains Delegate management, approval and attestation tasks to users or groups held in unmanaged domains Run ActiveRoles Server policies against objects held in unmanaged domains, provided that the policies require only read access to those objects Provision users from unmanaged domains with linked Exchange mailboxes held in a separate managed forest Populate Managed Units with objects from unmanaged domains Since ActiveRoles Server has read-only access to unmanaged domains, it cannot: Create, move, or delete objects in unmanaged domains Change any properties of objects held in unmanaged domains Run any group membership related policies against the groups in unmanaged domains, including the Group Family and Dynamic Group policies Run any auto-provisioning or deprovisioning policies against the users or groups held in unmanaged domains Run any workflow that makes changes to objects in unmanaged domains Publish groups from unmanaged domains to Self-Service Manager Restore objects from Active Directory Recycle Bin in unmanaged domains All domains that are registered with ActiveRoles Server are listed in the Domains area of ActiveRoles Server root page in the console. To distinguish unmanaged domains, the Available as unmanaged domain label appears next to the name of each unmanaged domain in the Domains area. The regular managed domains have the Available for management label next to their names. The unmanaged domain indication is also available on General tab in the Properties dialog box for each domain registration object held in the Managed Domains container. This is a read-only check box named Use as unmanaged domain, which is selected if the domain is unmanaged and cleared otherwise. Since the status of a domain (unmanaged or regular managed) can only be set when registering the domain, the Use as unmanaged domain check box cannot be cleared or selected on the General tab. Licensing of Unmanaged Domains An unmanaged domain is basically a domain that is registered with ActiveRoles Server for read-only access. If ActiveRoles Server will not be used to make changes in a domain, but will only need to select objects and retrieve data from that domain, then the domain can be registered as an unmanaged domain in order to reduce licensing costs. The reduction in the licensing cost stems from the fact that ActiveRoles Server counts the users in the unmanaged domains separately from the users in the other domains, featuring two user counts: one for the regular managed domains (those registered without the use of the unmanaged domain option) and another one for the unmanaged domains. The licensing model of ActiveRoles Server demands that the total number of the enabled user accounts in the regular managed domain should not exceed the licensed number of users, but this requirement does not apply to the unmanaged domains. The number of users in each unmanaged domain is evaluated separately and independently from the users count in the regular managed domains. Regardless of the users count in the regular managed domains, ActiveRoles Server allows each unmanaged domain to hold any number of enabled user accounts that does not exceed the licensed number of users. 30

31 Feature Guide ActiveRoles Server allows you to have any number of unmanaged domains, provided that the number of enabled user accounts in each unmanaged domain does not exceed the number of users indicated in your license for ActiveRoles Server or Active Roles Self-Service Manager. For instance, if your license allows for 10,000 users, then you can add any number of unmanaged domains each of which contains at most 10,000 enabled user accounts. Without the unmanaged domain option, you are limited to a total of 10,000 enabled user accounts in all the domains that are registered with ActiveRoles Server. To sum up, unmanaged domains are licensed by counting the number of enabled user account in each unmanaged domain, and then selecting the largest count. This count should not exceed the license count. For example, suppose two unmanaged domains are registered with ActiveRoles Server, one of which contains 5,000 enabled user accounts whereas the other one contains 10,000 enabled user accounts. In this case, the count of 10,000 is considered, so ActiveRoles Server requires a license for not less than 10,000 users. When the number of enabled user accounts in any one of the registered unmanaged domains exceeds the license count, a violation warning will automatically begin appearing when the ActiveRoles Server console or Web Interface is opened by the user. In this situation the customer should contact their Quest Sales representative to purchase the appropriate number of user licenses necessary to come back into compliance. Register an unmanaged domain using the ActiveRoles Server console: 1. In the console tree, select the ActiveRoles Server root node. 2. On the ActiveRoles Server page in the details pane, click the Add Domain button to start the wizard for registering a domain. 3. On the Domain Selection page in the wizard, supply the DNS name of the domain to be registered, and select the Use as unmanaged domain check box. Once selected, this option cannot be changed after the domain has been registered. Should you no longer want a domain to be unmanaged, you will need to unregister the domain (delete the corresponding object in the Managed Domains container) and then register the domain again, with the Use as unmanaged domain option unselected. 4. Follow the wizard pages to complete the registration of the domain. After completing the wizard, wait while ActiveRoles Server collects information about the newly added domain. Use the Refresh command to update the displayed domain status. As soon as the process of collecting domain information is completed, the Available as unmanaged domain label appears next to the name of the domain in the Domains area on the ActiveRoles Server root page. Support for Microsoft SQL Server 2008 R2 ActiveRoles Server now supports Microsoft SQL Server 2008 R2, to take advantage of high availability, industry-leading performance, and other significant enhancements engineered into this new technology from Microsoft. Any edition of SQL Server 2008 R2 can be used as a database or reporting services platform for ActiveRoles Server, with the limitation that ActiveRoles Server replication publishing is not available when you use SQL Server Express. SQL Server 2005 and SQL Server 2008 are also supported, which gives organizations the flexibility to maintain ActiveRoles Server data repositories using the database platform of their choice. 31

32 Quest ActiveRoles Server Advanced Mode of Select Groups Page in Self-Service Manager In Self-Service Manager the Select Groups page is used for selecting the groups to join. It appears when you click the Select Groups button on the Request Access page. By default, the capabilities of the Select Groups page are as follows: Only the groups that are published to Self-Service Manager are listed on the page. All published groups are listed, regardless of their location in the Active Directory domains. So, by default the Select Groups page does not allow you to: Select groups that are not published to Self-Service Manager Restrict the listed groups to those located in a particular domain or organizational unit If you need to overcome these limitations, you can switch the Select Groups page in advanced mode by customizing the configuration of the Web Interface site for self-administration. The following customization options are available: Extended Search Causes the Selected Groups page to search for both published and non-published groups. Advanced View Allows a search scope to be specified on the Select Groups page, so as to search for groups in a particular container rather than in all managed domains. You can enable any one or both of these options. If the Extended Search option is enabled, a search on the Select Groups page returns the groups whose name, display name, or any keyword contains the search string specified. The search results include both published and non-published groups from any managed domain. If the Extended Search option is disabled (this is the default setting), the search results list only published groups. If the Advanced View option is enabled, the Select Groups page offers a different user experience, summarized in the subsection that follows. Using the Select Groups page with the Advanced View option enabled Initially, the page lists published groups only. You can rebuild the list by searching for groups in a particular container. The name of the container to search is displayed in the Find in box. To choose a different container, click the Browse button next to the Find in box. The Name box is intended to supply a search string. You can type multiple search strings separated by semicolons (;). The search will look for groups that match any of the search strings. When you click the Search button, a search starts looking for groups in the container identified by the Find in box. The search results returns the groups whose name, display name, or any keyword contains the search string. To select a group, click the name of the group in the search results list. This adds the group to the list in the bottom area of the dialog box. If you have selected a group by mistake, you can cancel the selection by clicking the Remove button. Once you have selected all the groups you want, click OK. To enable any one or both of the Extended Search and Advanced View options, use the ActiveRoles Server console as follows. 32

33 Feature Guide To switch the Select Groups page to advanced mode 1. Verify that the console is in Raw view mode: Select View Mode, and then select the Raw Mode option. 2. In the console tree, select Configuration Application Configuration Web Interface. 3. In the details pane, double-click the object whose description reads Site for Self-Administration (32). 4. In the details pane, double-click Customization Settings. 5. Use the All Tasks Advanced Properties command on the WorkingCopy object in the details pane to modify the value of the edsawicommands attribute: To enable the Extended Search option, locate the <Setting Name="UseExtendedSearch" Value="false" /> XML element in the edsawicommands attribute value and change it to <Setting Name="UseExtendedSearch" Value="true" /> To enable the Advanced View option, locate the <Setting Name="ShowSimpleDialog" Value="true" /> XML element in the edsawicommands attribute value and change it to <Setting Name="ShowSimpleDialog" Value="false" /> Both of these XML elements are children of the XML element Task that has the ID attribute value of MyRequestAccess (<Task ID="MyRequestAccess"... >). 6. On the Self-Service Home page, select Customization Reload for the Web Interface configuration changes to take effect. 33

34 Quest ActiveRoles Server New Features Included in Version 6.5 ActiveRoles Server 6.7 inherits and improves upon the features of the previous versions of ActiveRoles Server. This section provides an overview of the new features introduced in ActiveRoles Server 6.5 and inherited by ActiveRoles Server 6.7. Implementing Rules and Roles Here you can find an overview of the features and enhancements relating to ActiveRoles Server s policies (administrative rules) and delegation model (administrative roles). Workflows ActiveRoles Server provides a rich workflow system for directory data management automation and integration. Based on Microsoft s Windows Workflows Foundation technology, this workflow system enables IT to define, automate and enforce management rules quickly and easily. Workflows extend the capabilities of ActiveRoles Server by delivering a framework that enables combining versatile management rules such as provisioning and de-provisioning of identity information in the directory, enforcement of policy rules on changes to identity data, routing data changes for approval, notifications of particular events and conditions, as well as the ability to implement custom actions using script technologies such as Microsoft Windows PowerShell. Suppose you need to provision user accounts based on data from external systems. The data is retrieved and then conveyed to the directory by using a service such as ActiveRoles Quick Connect that works in conjunction with ActiveRoles Server. A workflow can be created to coordinate the operations in account provisioning. For example, different rules can be applied for creating or updating accounts held in different containers. Workflows may also include approval rules that require certain changes to be authorized by designated persons (approvers). When designing an approval workflow, the administrator specifies which kind of operation causes the workflow to start, and adds approval rules to the workflow. The approval rules determine who is authorized to approve the operation, the required sequence of approvals, and who needs to be notified of approval tasks or decisions. By delivering notifications, workflows extend the reach of management process automation throughout the enterprise. Notification activities in a workflow let people be notified via about events, conditions or tasks awaiting their attention. For example, approval rules can notify of change requests pending approval, or separate notification rules can be applied to inform about data changes in the directory. Notification messages include all necessary supporting information, and provide hyperlinks enabling message recipients to take actions using a standard Web browser. About Workflow Processes The logic of an automated management process can be implemented by using administrative policies in ActiveRoles Server. Yet creating and maintaining complex, multi-step processes in that way can be challenging. Workflows provide a different approach, enabling IT administrators to define a management process graphically. This can be faster than building the process by applying individual policies, and it also makes the process easier to understand, explain and change. 34

35 Feature Guide The following diagram shows a workflow process created in the ActiveRoles Server console. In this simple example, upon a request to add a user to a certain group, the workflow first checks to see if the group has an owner. If the group has no owner, the requested changes are denied and the workflow is complete; otherwise, the changes are submitted to the group owner for approval. When approval is received, ActiveRoles Server applies the changes, adding the user to the group. On the process diagram, this step is referred to as Operation execution. If the owner rejects the changes, the workflow finishes on the previous (approval) step so that the changes are not applied. After the changes are made, the workflow sends an notification to the person who requested the changes, and then finishes. In the above example, the workflow manages the process of adding a user to a group according to the rules defined at design time. The rules constitute the workflow definition, and include the activities that occur within the process and the relationships between activities. An activity in a process definition can be a pre-defined function available out of the box, such as a request for approval or a notification of conditions that require user interaction, or it can be a custom function created using script technologies. A workflow process is started when the requested changes meet the conditions specified in the workflow definition. In the above example, the conditions might be set up so that the workflow starts whenever an ActiveRoles Server user has made changes to the membership list of a certain group. Once the conditions are fulfilled, the workflow process starts to drive the changes through the workflow definition, performing automated steps and, if necessary, requesting human interaction such as approval. 35

36 Quest ActiveRoles Server Use the ActiveRoles Server console to create a workflow definition, and then open the workflow definition in the Workflow Designer: 1. In the console tree, expand Configuration Policies, right-click Workflow, and select New Workflow Policy. 2. In the New Object wizard, type in a name and, optionally, a description for the new workflow. 3. Follow the steps in the wizard to finish creating the workflow definition. 4. In the console tree, click the workflow definition you have created. This opens the Workflow Designer window in the details pane, representing the workflow definition as a process diagram. About Workflow Start Conditions To deploy a workflow in ActiveRoles Server, you create a workflow definition, configure the start conditions for that workflow, and add and configure workflow activities. The workflow start conditions determine which operations cause the workflow to start. For example, an approval workflow could be configured so that any request to create a user in a specific container starts the workflow, thereby requiring approval for the request. You can specify the start conditions for a workflow by editing its definition in the Workflow Designer. When configuring workflow start conditions, you specify: A type of operation, such as Create, Rename, Modify or Delete; the workflow starts only if an operation of that type is requested. A type of object, such as User, Group or Computer; the workflow starts only if the operation requests changes to an object of that type. For the Modify operation type, a list of object properties; the workflow starts only if the operation requests changes to any of those properties of an object. The identity of an operation requestor (initiator), such as a user, group or service; the workflow starts only if the operation is requested on behalf of that identity. A container, such as an Organizational Unit or Managed Unit; the workflow starts only if the operation requests changes to, or creation of, an object in that container. Optionally, a filter that defines any additional conditions on entities involved in an operation; the workflow starts only if the operation satisfies those conditions. If no filter is set, then no additional conditions are in effect. Upon a request for any operation that meets all the start conditions specified on a workflow, the Administration Service matches the workflow to the request and runs the activities found in the workflow. Use the ActiveRoles Server console to view or change the start conditions for a workflow: 1. In the console tree, expand Configuration Policies Workflow, and select the workflow you want to configure. This opens the Workflow Designer window in the details pane, representing the workflow definition as a process diagram. 2. In the details pane, click the link above the process diagram. This opens a dialog box where you can view or change the workflow start conditions. 36

37 Feature Guide Workflow Activities Overview Activities are units of work, each of which contributes to the accomplishment of a workflow process. ActiveRoles Server offers a default set of activities that provide pre-defined functionality for approval, notification, control flow and conditions. Scripting can be used to have an activity perform custom functions. This section lists the types of activity that are included in ActiveRoles Server, and provides a brief description of each. For more information, see the Workflows chapter in the ActiveRoles Server Administrator Guide. Script Activity Script activities are typically used to perform automated steps in a workflow process. A Script activity is defined by a script module created in ActiveRoles Server. Each script module contains script code implementing certain functions. New script modules can freely be added and the script contained in a script module can be developed and revised as necessary. This provides a mechanism for creating custom functions, enabling the extensibility of actions performed by a workflow. Approval Activity An Approval activity, also referred to as an approval rule, represents a decision point in a workflow that is used to obtain authorization from a person before continuing the workflow. Workflow start conditions determine which operations start the workflow and the approval rules added to the workflow determine who is designated to approve the operation, the required sequence of approvals, and who needs to be notified of approval tasks or decisions. Notification Activity A Notification activity in a workflow is used to send an notification to the specified users or groups about the completion of the operation that started the workflow. For example, with ActiveRoles Server Self-Service allowing users to add themselves to a distribution list, you could configure a Notification activity to send an to the distribution list owner whenever users join or leave the distribution list. If-Else Activity An If-Else activity is used to conditionally run one of two or more alternative branches depending on the conditions defined on the branches. It contains an ordered set of branches and runs the first branch whose condition evaluates to TRUE. You can add as many branches as you want to an If-Else activity, and you can add as many activities as you want to every branch. Stop/Break Activity A Stop/Break activity is used to immediately end all activities of a running workflow instance. You can use it within a branch of an If-Else activity, so as to terminate the workflow once a certain condition occurs. An example is a requirement for the validation of the requested data changes so as to deny certain operations because applying such operations would result in unacceptable data being written to the directory. To address this requirement, you could use a workflow with an If-Else branch that runs upon detection of unacceptable data in the requested operation, and add a Stop/Break activity to that branch. In this way, your workflow would block the unwanted operations, safeguarding the directory data. 37

38 Quest ActiveRoles Server Use the ActiveRoles Server console to add an activity to a workflow: 1. In the console tree, expand Configuration Policies Workflow, and select the workflow to which you want to add an activity. This opens the Workflow Designer window in the details pane, representing the workflow definition as a process diagram. 2. In the details pane, drag the activity from the left panel onto the process diagram. 3. Right-click the name of the activity on the process diagram and click Properties. 4. Use the Properties dialog box to configure the activity. For instructions on how to configure activities, see the Workflows chapter in the ActiveRoles Server Administrator Guide. Flexible Options for Multiple Approvals Workflows in ActiveRoles Server provide the ability to implement multi-level approval scenarios where changes require approval by several persons in sequence. For example, it is possible to establish an approval process that first submits each request to join a particular group to the manager of that group for approval and then, if approval is received from the manager, submits the request for additional approval by an IT person. An approval workflow can be configured to require: Single approval The requested changes can be approved by a single party. Multiple approvals in serial order The requested changes need to be approved by multiple parties, with subsequent approvals not taking place until its antecedent is approved. Unlimited levels of serial approval are supported. Multiple approvals in parallel order The requested changes need to be approved by multiple parties, but all parties are contacted at once with the request. The process does not continue until all contacted parties have approved the request. To implement a single-approval scenario, add only one approval activity to the workflow. To implement a serial-approval scenario, add two or more approval activities to the same workflow. To implement a parallel-approval scenario, create two or more workflow definitions with the same workflow start conditions, and add an approval activity to each. Using Tokens in Notification Messages When configuring notification messages in a workflow activity, you can add dynamic content to the message subject or message body. Instructions that substitute dynamic content in notification message templates are referred to as tokens. You can select tokens from a list and add them to the message template. Each token causes the message text to include a certain piece of information in place of the token. When generating a message, the system gathers information substituted by the tokens, and adds that information to the message. 38

39 Feature Guide Use the ActiveRoles Server console to view or change a notification message template: 1. In the Workflow Designer, drag the Notification activity onto the process diagram to add a notification rule to the workflow. 2. Double-click the notification rule to open its Properties page. 3. Click Add in the Events, Recipients and Messages area on the Properties page. 4. Click Modify in the Notification message area on the Notification Settings page. This opens a page where you can view or modify the current template. 5. Click the Insert Token button, and then select a token to insert. The token is inserted at the cursor position in the template code on that page. You can view a brief description of the token in the text box under the list of available tokens. Approval and Workflow Related Reports The ActiveRoles Server Report Pack has been extended to include reports for monitoring workflow and approval processes. The following reports are now available for this purpose: Approvals and Rejections Summarizes the history of approvals and rejections during the specified period of time. You can use this report to audit approver actions. Workflow Monitoring Summarizes events specific to ActiveRoles Server workflow, and groups them either by operation that starts workflow or by workflow name. You can use this report to monitor the execution of workflow instances. Provided that the ActiveRoles Server Report Pack is installed, you can use SSRS Report Manager to view the workflow monitoring reports: On the Contents page in SSRS Report Manager, click QKP and navigate to the ActiveRoles Server > > ActiveRoles Server Tracking Log > ActiveRoles Server Workflow folder. For instructions on how to install the ActiveRoles Server Report Pack, see the Steps to Install the Reporting Components section in the ActiveRoles Server Quick Start Guide. For instructions on how to create and view ActiveRoles Server reports, see the ActiveRoles Server Reporting chapter in the ActiveRoles Server Administrator Guide. 39

40 Quest ActiveRoles Server Policy Extensions In previous versions of ActiveRoles Server, administrators could configure policies of only pre-defined types. The list of policy types in the ActiveRoles Server console was restricted to the types available out of the box, such as Home Folder AutoProvisioning or User Account Deprovisioning. There was no way to extend the list by adding new types of policy. Each policy type determines a certain policy action (for example, creating a home folder for a user account) together with a collection of policy parameters to configure the policy action (for example, parameters that specify the network location where to create home folders). The latest version of ActiveRoles Server builds upon this concept, providing the ability to implement and deploy custom types of policy. It enables custom policy types to be created as necessary, and listed along with the pre-defined policy types, allowing administrators to configure policies that perform custom actions determined by those new types of policy. ActiveRoles Server allows the creation of custom policies based on the Script Execution built-in policy type. However, creating and configuring a script policy from scratch can be time-consuming. Custom policy types provide a way to mitigate this overhead. Once a custom policy type is deployed that points to a particular script, administrators can easily configure and apply policies of that type, having those policies perform the actions determined by the script. The policy script also defines the policy parameters specific to the policy type. Custom policy types provide an extensible mechanism for deploying custom policies. This capability is implemented by using the Policy Type object class. Policy Type objects can be created by using the ActiveRoles Server console, with each object representing a certain type of custom policy. Design Elements The policy extensibility feature is designed around two interactions: policy type deployment and policy type usage. Policy Type Deployment The deployment process involves the development of a script that implements the policy action and declares the policy parameters; the creation of a Script Module containing that script; and the creation a Policy Type object referring to that Script Module. To deploy a policy type to a different environment, an administrator can export the policy type to an export file in the source environment and then import the file in the destination environment. Using export files makes it easy to distribute custom policy types. Policy Type Usage This is the process of configuring policies. It occurs when an administrator creates a new Policy Object or adds policies to an existing Policy Object. For example, the wizard for creating a Policy Object includes a page that prompts to select a policy. The page lists the policy types defined in ActiveRoles Server, including the custom policy types. If a custom policy type is selected, the wizard provides a page for configuring the policy parameters specific to that policy type. Once the wizard is completed, the Policy Object contains a fully functional policy of the selected custom type. ActiveRoles Server provides a graphical user interface, complete with a programming interface, for creating and managing custom policy types. Using those interfaces, ActiveRoles Server policies can be extended to meet the needs of a particular environment. ActiveRoles Server also has a deployment mechanism by which administrators put new types of policy into operation. 40

41 Feature Guide Since policy extension involves two interactions, ActiveRoles Server provides solutions in both areas. The Administration Service maintains policy type definitions, exposing policy types to its clients such as the ActiveRoles Server console or ADSI Provider. The console can be used to: Create a new custom policy type, either from scratch or by importing a policy type that was exported from another environment. Make changes to the definition of an existing custom policy type. Add a policy of a particular custom type to a Policy Object, making the necessary changes to the policy parameters provided for by the policy type definition. Normally, an ActiveRoles Server expert develops a custom policy type in a separate environment, and then exports the policy type to an export file. An ActiveRoles Server administrator deploys the policy type in the production environment by importing the export file. After that, the ActiveRoles Server console can be used to configure and apply policies of the new type. Use the ActiveRoles Server console to create a custom policy type: 1. In the console tree, expand Configuration Server Configuration, right-click Policy Types, and select New Policy Type. 2. In the New Object - Policy Type wizard, type a name, a display name and, optionally, a description for the new object. The display name and description are displayed on the page for selecting a policy, in the wizards that are used to configure Policy Objects. 3. Click Next. 4. Click Browse and select the Script Module containing the script that will be run by the policies of this policy type. The Script Module must exist under the Configuration/Script Modules container and hold a policy script. For information about policy scripts, see the ActiveRoles Server SDK documentation. 5. In the Policy Type category area, click Provisioning. The policy types that have the Provisioning option selected appear on the page for selecting a policy in the wizard that is used to create a provisioning Policy Object. 6. Click Next and follow the steps in the wizard to complete the creation of the new Policy Type object. Use the ActiveRoles Server console to view or select the custom policy type you have created: 1. In the console tree, expand Configuration Policies, right-click Administration, and select New Provisioning Policy. 2. Follow the steps in the New Provisioning Policy Object Wizard until you reach the Policy to Configure page. 3. In the upper box on the Policy to Configure page, click the display name of the custom policy type this is the display name you specified when creating the custom policy type. 4. In the lower box on the Policy to Configure page, view the description of the custom policy type this is the description you specified when creating the custom policy type. 41

42 Quest ActiveRoles Server Windows PowerShell Scripting Custom policies and workflow activities can be created using Windows PowerShell a command-line shell and scripting language designed especially for system administration. ActiveRoles Server provides an environment for authoring PowerShell-based script modules, and leverages the Windows PowerShell runtime for executing policies and activities that use PowerShell-based script modules. Use the ActiveRoles Server console to create a script module for PowerShell scripting: 1. In the console tree, expand Configuration, right-click Script Modules, and then select New Script Module. 2. From the Script language list, select PowerShell. 3. Follow the wizard pages to complete the creation of the script module. Use the ActiveRoles Server console to edit the script module you have created: 1. In the console tree, under Script Modules, right-click the script module and then click Edit Script. 2. In the details pane, view or change the script. 3. When finished, right-click the script module in the console tree and then click Save Script on Server. For instructions on how to author PowerShell-based script modules, refer to the ActiveRoles Server SDK documentation. Group Deprovisioning ActiveRoles Server now provides for the Deprovision function on groups, enabling a group to be made temporarily unusable. For example, when Attestation Review for a group is not completed in a timely manner, which may pose a potential threat, group deprovisioning can be used as a remediation measure. As applied to a group, deprovisioning refers to a set of changes being made in order to prevent the use of the group. What changes to make is determined by deprovisioning policies. ActiveRoles Server comes with a default deprovisioning policy, and allows new deprovisioning policies to be created and configured as needed. Both the ActiveRoles Server console and Web Interface provide the Deprovision command on groups. When performing this command, ActiveRoles Server makes all the changes prescribed by the deprovisioning policies and creates a detailed report about the changes that were made along with information about success or failure of each change. One more way to apply deprovisioning on groups is to configure Attestation Review in ActiveRoles Server so that the groups not attested within required time frame are automatically deprovisioned. Attestation Review also provides the option to let an IT administrator manually deprovision such groups. 42

43 Feature Guide Group Deprovisioning Policies ActiveRoles Server offers a number of policy types to control the group deprovisioning process: Group Object Deprovisioning Group Object Relocation Group Object Permanent Deletion Notification Distribution Report Distribution Script Execution Group Object Deprovisioning Group object deprovisioning policy specifies the changes to make to the group object in Active Directory in order to prevent the use of the group. It is intended to perform the following tasks when deprovisioning a group: Hide the group from the Global Address List (GAL), to prevent access to the group from Exchange Server client applications such as Microsoft Outlook. This task is applicable to distribution groups or mail-enabled security groups. Change the type of the group from Security to Distribution, to revoke access rights from the group. This task is applicable only to security groups. Rename the group, to distinguish deprovisioned groups by name. This task can be configured to compose a name based on other properties of the group. Remove members from the group, to revoke user access to resources controlled by the group. This task has the option to specify the members that should not be removed from the group. In addition, the policy can be configured to change or clear any other properties of a group, such as the pre-windows 2000 name, addresses, or description. Group Object Relocation Group relocation policy is intended to perform the task of moving deprovisioned groups to specified organizational units. Moving deprovisioned groups to a different location removes such groups from the control of the administrators that are responsible for management of the organizational units in which those groups originally reside. This policy can also be configured not to move deprovisioned groups. Group Object Permanent Deletion Group deletion policy is intended to perform the task of deleting deprovisioned groups. Deprovisioned groups are retained for a specified amount of time before they are permanently deleted. This policy can also be configured not to delete deprovisioned groups. One more option is to delete deprovisioned groups immediately to Active Directory Recycle Bin. When processing a request to deprovision a group, ActiveRoles Server uses this policy to determine whether to schedule the deprovisioned group for deletion. When scheduled for deletion, a group is permanently deleted after a certain time period, referred to as retention period. The retention period option specifies the number of days to retain deprovisioned groups. ActiveRoles Server permanently deletes a group after the specified number of days has passed since the group was deprovisioned. 43

44 Quest ActiveRoles Server One more option of group deletion policy is to delete deprovisioned groups to Active Directory Recycled Bin. With this option, ActiveRoles Server checks to see whether Recycle Bin is enabled in the domain of the group (this requires the Active Directory forest functional level of Windows Server 2008 R2), and then, if Recycle Bin is enabled, deletes the deprovisioned group immediately. Should the need arise to recover a group that was deprovisioned to Recycle Bin, ActiveRoles Server can be used to restore (un-delete) the group from Recycle Bin and then perform the Undo Deprovisioning operation on that group. Notification Distribution Policy Notification distribution policy is intended to send an notification upon a request to perform the deprovisioning operation. The primary purpose is to notify designated persons about a deprovisioning request, so they could take additional deprovisioning-related actions if necessary. The policy specifies the notification recipients and message, and determines the outgoing mail server (SMTP). The subject and the body of the message may include auto-text fields (tokens) to customize the message, making it more meaningful to the recipients. A notification message cannot be considered as an indication of success or failure of the deprovisioning operation. It only indicates that a deprovisioning operation has been requested. To inform of deprovisioning results, ActiveRoles Server offers report distribution policy. Report Distribution Policy Report distribution policy is intended to send a report on deprovisioning results upon completion of a deprovisioning operation. The report includes a list of actions taken during the deprovisioning operation. For each action, the report informs of whether the action is completed successfully, and provides information about the action results. The policy specifies the report recipients, the subject of the report message, and whether to send a report if no errors occurred. Similar to the notification messages, the message subject can be configured to include auto-text fields (tokens). Report messages are delivered via by using SMTP transport. Script Execution Policy Script execution policy can be used to run supplementary scripts upon requests to deprovision groups. Scripting allows custom actions to be included in the group deprovisioning process. A script can be associated with a deprovision operation so that the policy runs it when the operation is requested or after the operation is completed. Use the ActiveRoles Server console to configure a group deprovisioning policy: 1. Start the New Deprovisioning Policy Object wizard: In the console tree, expand Configuration Policies, right-click Administration, and select New Deprovisioning Policy. 2. Follow the wizard steps until you reach the Policy to Configure page. 3. In the upper box on the Policy to Configure page, expand the Group Deprovisioning Policies node and click the policy you want to add to the Policy Object. 4. Follow the wizard steps to configure the policy and complete the creation of the Policy Object. Use the ActiveRoles Server console to deprovision a group: Right-click the group and then click Deprovision. 44

45 Feature Guide Use the ActiveRoles Server Web Interface to deprovision a group: Click the group and then choose Deprovision from the drop-down command menu. Default Deprovisioning Options ActiveRoles Server ships with a built-in Policy Object that specifies the operations to perform when deprovisioning a group. It determines the default effect of the Deprovision command on groups, which can be altered by adjusting and applying additional group deprovisioning policies. It is possible to modify the built-in Policy Object, as well as to create and configure additional Policy Objects to define group deprovisioning policies. The following table summarizes the default deprovisioning policy options for groups. If you do not add, remove or change deprovisioning policies, ActiveRoles Server operates in accordance with these options when carrying out the Deprovision command on a group. POLICY Group Object Deprovisioning Group Object Relocation Group Object Permanent Deletion OPTIONS Change the group type from Security to Distribution Hide the group from the Global Address List (GAL) Change the group name to include the suffix deprovisioned followed by the date when the group was deprovisioned Remove all members from the group Fill in the group description to state that this group is deprovisioned Clear certain properties of the group, to stop the publication of the group in Self-Service Manager Do not move the group from the organizational unit in which the group was located at the time of deprovisioning Do not delete the group How to start Use the ActiveRoles Server console to view or change the default deprovisioning options for groups: 1. In the console tree, expand Configuration Policies Administration, and select Builtin under Administration. 2. In the details pane, double-click Built-in Policy - Group Default Deprovisioning. 3. On the Policies tab in the Properties dialog box, click a policy, and then click View/Edit to access the policy options. 45

46 Quest ActiveRoles Server Delegation of the Deprovisioning Task The group deprovisioning task can be delegated to any group or user. A dedicated Access Template is provided for that purpose so the administrator can easily delegate the use of the Deprovision command on groups. The delegation of the deprovisioning task only authorizes the delegated users to start the deprovisioning process on groups, and does not give them any additional rights, such as the authority to create, change, or delete a group. Use the ActiveRoles Server console to delegate the group deprovisioning task: 1. In the console tree, expand Configuration Access Templates, and select Active Directory under Access Templates. 2. In the details pane, right-click Groups - Perform Deprovision Tasks, and click Links. 3. Click Add in the Links window, and follow the instructions in the Delegation of Control wizard to apply the Access Template. Report on Deprovisioning Results Once a group is deprovisioned, ActiveRoles Server generates a report to inform about the results of the deprovisioning operation. The report is displayed upon completion of the deprovisioning operation, and can also be accessed by using a special command on the deprovisioned group. In addition, a policy can be configured to send the report via . The report includes a list of actions taken during the deprovisioning of the group. For each action, the report informs of success or failure of the action. In the event of a failure, the report gives a description of the error situation. For deprovisioning policies of the Script Execution category, ActiveRoles Server provides the ability to add custom information to the report on deprovisioning results. When designing a script to implement a deprovisioning action, you can use a programmatic interface to record information in the report (see ActiveRoles Server SDK for details). Use the ActiveRoles Server console to view the deprovisioning results on a deprovisioned group: Right-click the group and then click Deprovisioning Results. Use the ActiveRoles Server Web Interface to view the deprovisioning results on a deprovisioned group: Click the group and then choose Deprovisioning Results from the drop-down command menu. 46

47 Feature Guide Ability to Undo Deprovisioning ActiveRoles Server provides the ability to restore deprovisioned groups. The purpose of this operation, referred to as Undo Deprovisioning, is to roll back the changes that were made to a group by the Deprovision operation. When a deprovisioned group needs to be restored (for example, a group was deprovisioned by mistake), Undo Deprovisioning allows the group to be quickly returned to the state it was in before the changes were made. Undo Deprovisioning rolls back the changes that were made to the group in accord with the standard deprovisioning policies. For example, assume the deprovisioning policy is configured so that the Deprovision operation: Removes all members from the group Renames the group Moves the group to a certain container In this case, the Undo Deprovisioning operation: Restores the original membership list of the group, as it was at the time of deprovisioning Renames the group, restoring the original name of the group Moves the group to the container that held the group at the time of deprovisioning Similar behavior is in effect for the other deprovisioning policies: If the Deprovision operation hides the group from the Global Address List (GAL), Undo Deprovisioning restores the visibility of the group in the GAL. If the Deprovision operation changes the group type from Security to Distribution, Undo Deprovisioning sets the group type back to Security. If the Deprovision operation changes any other properties of the group, Undo Deprovisioning restores the original property values. Both the ActiveRoles Server console and Web Interface provide the Undo Deprovisioning command on deprovisioned groups. When selected on a deprovisioned group, this command originates a request to restore the group. Upon receipt of the request, ActiveRoles Server performs all necessary actions to undo the results of deprovisioning on the group, and provides a detailed report of the actions that were taken along with information about success or failure of each action. Use the ActiveRoles Server console to restore a deprovisioned group: Right-click the group and then click Undo Deprovisioning. Use the ActiveRoles Server Web Interface to restore a deprovisioned group: Click the group and then choose Deprovisioning Results from the drop-down command menu. 47

48 Quest ActiveRoles Server Delegation of the Undo Deprovisioning Task The task of restoring deprovisioned groups can be delegated to any group or user. A dedicated Access Template is provided for that purpose so the administrator can easily delegate the use of the Undo Deprovisioning command on groups. The delegation of the Undo Deprovisioning task only authorizes the delegated users to start the restoration process on deprovisioned groups, and does not give them any additional rights, such as the authority to create, change, or delete a group. Use the ActiveRoles Server console to delegate the Undo Deprovisioning task on groups: 1. In the console tree, expand Configuration Access Templates, and select Active Directory under Access Templates. 2. In the details pane, right-click Groups - Perform Undo Deprovision Tasks, and click Links. 3. Click Add in the Links window, and follow the instructions in the Delegation of Control wizard to apply the Access Template. Report on Results of Undo Deprovisioning Once a deprovisioned group is restored, ActiveRoles Server generates a report to inform about the results of the Undo Deprovisioning operation. The report is displayed upon completion of the operation. The report includes a list of actions that were taken by the Undo Deprovisioning operation. For each action, the report informs of success or failure of the action. In the event of a failure, the report gives a description of the error situation. With a script-based policy applied so that the Undo Deprovisioning operation performs custom actions, it is possible for a script to add custom information to the report about results of undo deprovisioning. A programmatic interface can be used to record information in the report (see ActiveRoles Server SDK for details). Use the ActiveRoles Server console to view results of restoring a deprovisioned group: Right-click a deprovisioned group and then click Undo Deprovisioning. Use the ActiveRoles Server Web Interface to view results of restoring a deprovisioned group: Click a deprovisioned group and then choose Undo Deprovisioning from the drop-down command menu. 48

49 Feature Guide New Attestation Review Configuration Settings The Attestation Review configuration settings have been extended to include the following: Attestors This setting specifies who is authorized to review and certify groups in the course of Attestation Review. Remediation This setting provides the ability to choose if the groups that failed to be reviewed should be automatically deprovisioned upon the completion of Attestation Review. Attestors Setting The attestors setting determines who is authorized to perform Attestation Review. This could be the primary owners (managers) or secondary owners of the groups to review. Attestation Review can be configured with any one or both of these options: Primary owner (manager) of a group is authorized to certify that group Indicates that the managers of the groups are expected to perform Attestation Review. Secondary owners of a group are authorized to certify that group Indicates that other owners of the groups are expected to perform Attestation Review. The owners of a group are specified on the Managed By page for that group, in the ActiveRoles Server console or Web Interface. The name of the primary owner (manager) is displayed at the top of the page. The secondary owners are listed at the bottom of the page. In case of multiple owners, Attestation Review for a group is completed as soon as any one of the owners has certified that group. Use the ActiveRoles Server console to view or change the Attestors setting: In the Attestation Review Configuration panel, observe the Attestors area on the General page. Remediation Setting The remediation setting specifies whether the groups that are not attested within the Attestation Review duration period should be deprovisioned automatically; another option is to let the supervisor deprovision non-attested groups manually. Attestation Review can be configured to apply one of these options to any group that is not attested within the Attestation Review duration period: Let Supervisor deprovision the group as needed Indicates that the group will not be deprovisioned automatically, enabling the Attestation Review supervisor to decide whether the group needs to be deprovisioned and deprovision the group, if necessary. Deprovision the group automatically Causes ActiveRoles Server to deprovision the group upon the completion of Attestation Review. As applied to a group, deprovisioning refers to a set of changes being made in order to prevent the use of the group. What changes to make is determined by deprovisioning policies. If Attestation Review for a group is not completed in a timely manner, which may pose a potential threat, group deprovisioning can be used as a remediation measure. 49

50 Quest ActiveRoles Server Use the ActiveRoles Server console to view or change the Remediation setting: In the Attestation Review Configuration panel, observe the Remediation area on the General page. Using Tokens in Notification Messages When configuring Attestation Review notification messages, you can add dynamic content to the message subject or message body. Instructions that substitute dynamic content in notification message templates are referred to as tokens. You can select tokens from a list and add them to the message template. Each token causes the message text to include a certain piece of information in place of the token. When generating a message, the system gathers information substituted by the tokens, and adds that information to the message. Use the ActiveRoles Server console to view or change a notification message template: 1. In the Attestation Review Configuration panel, click the Notification tab. 2. Click Add in the Notification settings area. 3. Click Edit in the Notification Message area on the Notification Settings page. This opens a page where you can view or modify the current template. 4. Click the Insert Token button, and then select a token to insert. The token is inserted at the cursor position in the template code on that page. You can view a brief description of the token in the text box under the list of available tokens. "Policies" Node in the ActiveRoles Server Console Tree All containers that hold the data specific to administrative policies and rules are now grouped together in a single place the Configuration/Policies node in the ActiveRoles Server console tree. This makes it easier to locate the starting point for managing the data that controls the provisioning, deprovisioning and workflow processes in ActiveRoles Server. The Attestation Reviews container has also been moved to the Policies node, so console users no longer need to traverse the Configuration Server Configuration branch in order to access the Attestation Review related data. In the ActiveRoles Server console tree, expand Configuration Policies and then click these items under Policies: To access Policy Objects, click Administration. To create a new Policy Object, right-click Administration, point to New, and then click Provisioning Policy or Deprovisioning Policy. To access Attestation Review configurations, click Attestation Review. To create a new Attestation Review configuration, right-click Attestation Review and select New Attestation Review Policy. To access Workflow Definitions, click Workflow. To create a new Workflow definition, right-click Workflow and select New Workflow Policy. 50

51 Feature Guide Delegating Mailbox Management Tasks ActiveRoles Server provides the ability to create and administer various types of mailbox that are available in Exchange Server 2007 or later. The supported mailbox types include user mailboxes as well as room, equipment, linked and shared mailboxes. ActiveRoles Server makes it possible to delegate the tasks of creating and managing mailboxes with very fine granularity. The delegated administrators may be allowed to create and administer mailboxes of any type, or they may be allowed to create and administer only a particular type of mailbox. One more option is to delegate only the tasks specific to the mailbox types other than user mailbox. A number of Access Templates are provided for the purpose of mailbox management tasks delegation. These include: ACCESS TEMPLATE NAME Exchange - Perform Exchange Tasks Exchange - Manage Resource, Linked and Shared Mailboxes Exchange - Create User Mailboxes Exchange - Create Room Mailboxes Exchange - Create Equipment Mailboxes Exchange - Create Linked Mailboxes Exchange - Create Shared Mailboxes DESCRIPTION Authorizes the delegated administrators to: Create mailboxes of any type Perform any tasks in the Exchange Task Wizard View any properties of users, groups and contacts Authorizes the delegated administrators to: Create mailboxes of any type other than user mailbox Perform the tasks in the Exchange Task Wizard that apply to the room, equipment, linked, or shared mailbox type View any properties of users Authorizes the delegated administrators to create new user mailboxes. Authorizes the delegated administrators to create new room mailboxes. Authorizes the delegated administrators to create new equipment mailboxes. Authorizes the delegated administrators to create new linked mailboxes. Authorizes the delegated administrators to create new shared mailboxes. Use the ActiveRoles Server console to delegate mailbox management tasks: 1. In the console tree, expand Configuration Access Templates, and select Exchange under Access Templates. 2. In the details pane, right-click the appropriate Access Template, and click Links. 3. Click Add in the Links window, and follow the instructions in the Delegation of Control wizard to apply the Access Template. To delegate the task of creating a particular mailbox type, select Configuration Access Templates Exchange Advanced in the console tree, and then apply the appropriate Access Template from the Advanced container. 51

52 Quest ActiveRoles Server Delegating Task of Adding Self to Groups ActiveRoles Server supports the Add or remove self as a member permission, which is used to allow users to add or remove their own accounts from groups. Thus, publishing a group in ActiveRoles Server effectively gives that permission to end-users, enabling them to use Self-Service Manager for requesting self-membership in that group. Use the ActiveRoles Server console to authorize any users to add or remove themselves from the groups located in a certain Managed Unit: 1. Right-click the Managed Unit and click Delegate Control. 2. Click Add in the ActiveRoles Server Security window to start the Delegation of Control Wizard. 3. Use the Delegation of Control Wizard to apply the Add/Remove Self As Member Access Template to the Managed Unit. When prompted to select users or groups to which you want to delegate control, click Add and select the Authenticated Users built-in account. The Add/Remove Self As Member Access Template is located in the Configuration/Access Templates/Active Directory/Advanced container. A Group as a Manager or Owner of another Group With earlier versions of ActiveRoles Server only a user or contact could be set as the manager of a group. You could not assign a group to the manager role on another group. The latest version of ActiveRoles Server removes this restriction, allowing you to assign management of a group to a group. This may be helpful, for example, in a scenario where the task of managing a group needs to be delegated to the group itself. The latest version of ActiveRoles Server also removes the limitation on the number of group owners. In addition to the manager (also referred to as the primary owner), any number of secondary owners can be assigned to a group for the purpose of group management load balancing. It is possible to designate any user, contact or group as a secondary owner. If you assign a group to the owner or manager role, all members of that group are assigned to the role. The manager and owners of a group are specified on the Managed By page for that group, in the ActiveRoles Server console or Web Interface. The page displays the name and other properties of the manager, and includes a separate area for designating secondary owners. In ActiveRoles Server, the manager is also referred to as the primary owner. The Managed By page can also be used to specify whether the primary owner (manager) or secondary owners are authorized to add or remove members from the group. It is possible to do this separately for the primary and secondary owners: only the primary owner or only the secondary owners might be allowed to change the group membership list. When you select the option to allow the manager to update the membership list of a group, you cause ActiveRoles Server to create an Access Template link with the following settings: Groups - Read/Write Group Members (held in Configuration/Access Templates/Active Directory/Advanced/) as Access Template The group as the securable object The manger object as the security principal 52

53 Feature Guide The permission settings defined by the Access Template are replicated to Active Directory, so that the manager can update the membership list by using not only ActiveRoles Server but also any other administrative tool that supports the task of adding or removing group members (for example, Microsoft Outlook). Links with that same Access Template are also created by the option that allows secondary owners to change the group membership list, with the only difference being that ActiveRoles Server adds a separate link for each of the secondary owners. As a result, when you select that option, every user or group designated as a secondary owner is given the right to add or remove members from the group. Use the ActiveRoles Server console to assign management of group A to group B: On the Managed By tab in the Properties dialog box for group A, click the Change button and then use the Select Object dialog box to select group B. The above example assumes that group A and group B are from the same domain. If you want to assign management of group A to a group from a different domain, you can do this by adding a secondary owner for group A: 1. On the Managed By tab in the Properties dialog box for group A, click the button next to the Secondary owners box. 2. In the Add or Remove Owners dialog box, click Add and then use the Select Objects dialog box to select the group to which you want to assign management of group A. Deprovisioning Users or Groups to Recycle Bin The policy that controls the deletion of deprovisioned objects now provides the option to leverage Active Directory Recycle Bin a new feature of Windows Server 2008 R2. With Recycle Bin enabled in an Active Directory domain, you can configure a policy that immediately deletes a user or group in that domain once the user or group has been deprovisioned. The deletion guarantees that the deprovisioned object cannot be used while Recycle Bin ensures that the object can be restored, if necessary, without any data loss. With the option to deprovision objects to Recycled Bin, ActiveRoles Server checks to see whether Recycle Bin is enabled in the domain of the object (this requires the Active Directory forest functional level of Windows Server 2008 R2), and then, if Recycle Bin is enabled, deletes the deprovisioned object immediately. Should the need arise to recover an object that was deprovisioned to Recycle Bin, ActiveRoles Server can be used to restore (un-delete) the object from Recycle Bin and then perform the Undo Deprovisioning operation on that object. Note that all the other deprovisioning policies that are in effect are executed prior to the deletion. This ensures that restoring a deprovisioned object from Recycle Bin leaves the object in the deprovisioned state. The Undo Deprovisioning command appears on the un-deleted object, allowing you to roll-back the changes that were made to the object in accordance with the deprovisioning policies. Use the ActiveRoles Server console to add a policy to deprovision user objects to Recycle Bin: 1. In the console tree, select Configuration Policies Administration Builtin. 2. In the details pane, double-lick Built-in Policy - User Default Deprovisioning. 53

54 Quest ActiveRoles Server 3. On the Policies tab in the Built-in Policy - User Default Deprovisioning Properties dialog box, double-click the Does not delete user account policy. 4. On the Options tab in the User Account Permanent Deletion Policy Properties dialog box, click Delete the object to Active Directory Recycle Bin immediately. 5. Click OK to close the dialog boxes you opened. After you have made these changes, the Deprovision command on a user account executes all the deprovisioning policies defined in the Policy Object to deprovision the user, and then deletes the account if Recycle Bin is enabled in the domain of the account; otherwise, the account is not deleted. 54

55 Feature Guide Using ActiveRoles Server This section summarizes the features and enhancements that improve the user experience of those who use ActiveRoles Server to perform day-to-day administrative tasks. Group Owners An owner of a group is a person designated to perform certain management tasks on that group, such as: Add or remove members from the group Act as an approver to allow or deny changes to the group requested by other people (for example, requests to join or leave the group) Act as an attestor to review and certify the membership list of the group in the course of Attestation Review Deprovision or un-deprovision the group, if necessary With earlier versions of ActiveRoles Server the owner of a group was the same as the manager, that is, the user specified by the Managed By property of the group. This resulted in two major shortcomings: It was possible to designate only a single person as the owner of a single group The owner of a group had to belong to the same domain as the group itself The latest version of ActiveRoles Server removes these limitations by offering the Secondary Owners property on groups. This is a multi-valued property that can identify several users or groups as owners of a single group. In addition, the Managed By property can now be set not only to a user but also to a group. The owners of a group are specified on the Managed By page for that group, in the ActiveRoles Server console or Web Interface. The page displays the name and other properties of the manager, and includes a separate area for designating secondary owners. In ActiveRoles Server, the manager is also referred to as the primary owner. The Managed By page can be used to view or change the primary owner or secondary owners: The primary owner (manager) of a group can be a user or group from the same domain as the group itself. When the primary owner is set to a group, any member of that group may act as the primary owner. One or more secondary owners may be assigned to a single group, with each of the secondary owners being a user or group from any managed domain. This capability is especially useful in a resource forest topology where resources, such as Exchange distribution groups, are located in a forest other than the forest that holds the accounts of the owners. When a secondary owner is a group, then any member of that group may act as a secondary owner. The Managed By page can also be used to specify whether the primary owner (manager) or secondary owners are authorized to add or remove members from the group. It is possible to do this separately for the primary and secondary owners: thus, only the primary owner or only the secondary owners might be allowed to change the group membership list. 55

56 Quest ActiveRoles Server Another way to delegate group management tasks to owners of a group is to use built-in accounts that represent group owners. By selecting the Primary Owner (Managed By) or Secondary Owners built-in account as the delegated account in the Delegation of Control Wizard, you effectively delegate control of a group to the users or groups identified as the primary owner or secondary owners of that group, respectively. In this way you can authorize group owners to deprovision or un-deprovision the groups that they own. The Approval and Notification activities in ActiveRoles Server Workflow provide separate options for the primary or secondary owners to act as approvers or receive notifications. Supported are several types of approval: Single approval One level of approval is required, whether that be the primary owner or any one of the secondary owners. It is possible to configure approval workflow so that only the primary owner can approve changes to the group, or only secondary owners can approve changes. Multiple approvals in serial order Approvals by both the primary owner and one of the secondary owners are required, with a subsequent approval not taking place until its antecedent is approved. Multiple approvals in parallel order Approvals by both the primary owner and one of the secondary owners are required, but all owners are contacted at once with the request. The process does not continue until the primary owner and any one of the secondary owners have approved the requested changes to the group. Notification can be configured so that different owners are notified of different events. For each event type, it is possible to specify whether only the primary owner, only the secondary owners, or both the primary and secondary owners receive notifications about events of that type. When setting up Attestation Review, you can choose who is authorized to review and certify the groups to be attested. It is possible to configure Attestation Review so that only the primary owners, only secondary owners, or both the primary and secondary owners are allowed to perform attestation. With multiple owners, the review of a group is considered complete once any of the designated owners has certified the group. Use the ActiveRoles Server console to view or change the primary owner (manager) of a group: 1. Open the Properties page for the group and go to the Managed By tab. 2. Click Change under the Name box to specify the primary owner (manager). 3. Click Properties under the Name box, to examine the user or group that is currently assigned as the primary owner (manager). Use the ActiveRoles Server console to view, add or remove secondary owners of a group: 1. Open the Properties page for the group and go to the Managed By tab. 2. Click the button next to the Secondary owners box. 3. Use the Add or Remove Owners dialog box to view or change the list of secondary owners. 56

57 Feature Guide Use the Delegation of Control Wizard to delegate full control of groups in a certain organizational unit to the primary or secondary owners of the groups: 1. In the ActiveRoles Server console, right-click the organizational unit, click Delegate Control, and then click Add in the ActiveRoles Server Security dialog box to start the Delegation of Control Wizard. 2. On the Users or Groups page in the wizard, click Add, and then use the Select Objects dialog box to select the Primary Owner (Managed By) or Secondary Owners account. 3. On the Access Templates page in the wizard, expand the Active Directory node and select the Groups - Full Control Access Template. 4. Follow the wizard steps and accept the default settings. Use the ActiveRoles Server console to configure an approval workflow so that changes to any group in a certain organizational unit require approval by the primary owner of that group: 1. Create a workflow definition and add an approval activity to it. 2. Set the properties of the approval activity as follows: On the Approvers page, click Designate Approvers, and then select the Manager of operation target object check box. 3. Configure the workflow start conditions as follows: Choose Group as the target object type and Modify properties as the operation that starts the workflow. Configure the Initiator Conditions list to contain a single entry, with Initiator set to Any User and Container set to the organizational unit in question. 4. Save your changes to the workflow definition. Identifying Groups Owned by a Given User ActiveRoles Server provides the capability to view all groups for which a given user is assigned as a primary or secondary owner, from a single page in the ActiveRoles Server console or Web Interface. The Managed Resources page on a user account lists the groups owned by that user, and gives an indication of the ownership type on each group: Primary The user is the only manager of the group, specified by the Managed By property. Primary-Inherited The user belongs to the group specified by the Managed By property. Every member of such a group has the rights that are granted to the primary owner. Secondary The user is a secondary owner, specified by the Secondary Owners property. Secondary-Inherited The user belongs to a group specified by the Secondary Owners property. Every member of such a group has the rights that are granted to the secondary owners. By using the Managed Resources page, an IT administrator can detect issues with assigning group owners. For example, it is easy to identify the groups for which a given user is assigned as both the primary owner and a secondary owner. Use the ActiveRoles Server console to view the groups for which a given user is assigned as an owner: Open the Properties dialog box for that user account and click the Managed Resources tab. By default, the tab lists only the groups that fall under the primary ownership type. To extend the lists, select the check box on that tab. 57

58 Quest ActiveRoles Server Group Publication With the latest release of ActiveRoles Server, group publication is used to provide end-users with controlled access to their group memberships through the Self-Service Manager Web Interface. Publishing a group makes the group joinable by other people based on owner approval. Self-Service Manager enables users to submit requests to join or leave published groups, while ensuring that requests are granted only after approval by group owners. Approval workflow complements group publication, empowering group owners to control changes to group memberships. By enabling group owners to approve or reject membership requests, ActiveRoles Server helps reduce the burden of verifying whether or not a particular person should be allowed to join a particular group. This burden is shifted from IT staff to group owners who are in the best position to justify the need for group membership changes. Group publication is accomplished through adding groups to a built-in Managed Unit called Published Groups that has security and workflow controls configured to ensure the appropriate behavior of the published groups in ActiveRoles Server. A certain property of groups, called Is Published, determines which groups are members of that Managed Unit. When publishing a group, ActiveRoles Server sets the Is Published property on that group, thereby causing the group to be automatically added to the Published Groups Managed Unit. To facilitate group publication, both the ActiveRoles Server console and Web interface provide the Publish command on groups. The command is complemented by a dialog box that enables you to review and, if necessary, change a number of settings prior to starting the Publish operation. These include the group description, keywords and notes. In that dialog box, it is possible to choose whether changes to the group require approval and who should approve the changes: the primary owner, a secondary owner, or both. The Properties dialog box for a group includes the Publish tab where you can see whether the group is published. From that tab you can also publish or unpublish the group as well as specify who you want to approve changes to the group. The Unpublish command on a published group provides another way stop publishing the group, which effectively removes the group from the Published Groups Managed Unit. By default, the Published Groups Managed Unit has an Access Template applied to it that gives the authenticated users the right to add or remove their own accounts from groups. This Access Template, called Self-Service - My Memberships Management, defines the following permissions as applied to the group object type: Add/Remove self as member Enables a user to add or remove the user's own account from membership of a group. List, Read All Properties Enables users to view a group. Note that this Access Template does not authorize a user to view a list of groups of which that use is a member the Member Of list. An additional Access Template needs to be applied in order to enable the use of the My Access page in Self-Service Manager. The page is intended to display the Member Of list for the current user, so users must be given Read access to the Member Of property of their own accounts. This can be accomplished by applying the Self-Service - My Account Management Access Template to an Organizational Unit or Managed Unit that holds user accounts, with the rights assigned to the built-in account called Self. 58

59 Feature Guide The workflow rules on the published groups are defined by using two pre-defined workflow definitions: Approval by Primary Owner (Manager) Workflow to enforce the rule that changes to a group must be approved by the primary owner (manager) of the group. Approval by Secondary Owner Workflow to enforce the rule that changes to a group must be approved by any of the secondary owners of the group. Each of these workflow definitions is configured to start the approval workflow upon a request to add or remove a member from a group. The workflow start conditions also include a filter to consider the approval options on the group: the first workflow starts if the group is configured to require approval by the primary owner; the second workflow starts if approval by a secondary owner is required. With group publication, ActiveRoles Server helps reduce administrative overhead and improve productivity by empowering end users to perform group membership management tasks in a framework with delegated self-service. Tight security and approval workflow controls protect the published groups from unwanted access and ensure the accuracy of the membership lists, while Self-Service Manager provides a convenient, easy-to-use interface for managing groups and group memberships. Use the ActiveRoles Server console to publish a group to Self-Service Manager: Right-click the group and click Publish. Use the ActiveRoles Server console to view whether a group is published to Self-Service Manager: Open the Properties dialog box for the group and click the Publish tab. Use the ActiveRoles Server console to find all groups in a particular domain that are published to Self-Service Manager: 1. Right-click the domain and click Find. 2. In the Find list, click Groups. 3. Click the Group Type tab. 4. On the Group Type page, select the Show only groups check box, and then select the Published to Self-Service Manager check box. 5. Click Find Now. Use the ActiveRoles Server console to configure a group so that any changes to that group require approval by the primary owner: 1. Open the Properties dialog box for the group and click the Publish tab. 2. On the Publish tab, select the Approval by the primary owner (manager) of the group check box. 59

60 Quest ActiveRoles Server Membership Self-Management This new release of ActiveRoles Server extends the capabilities of ActiveRoles Self-Service Manager to let users view or change their memberships in Active Directory groups and Exchange distribution lists. A new section has been added to Self-Service Manager that lists the security and distribution groups of which the current user is a member, enabling the user to join or leave groups as needed. With the My Access section, Self-Service Manager empowers end users to manage their own access needs without involving the help desk and other IT departments. End users can now easily request membership in appropriate security groups allowing access to resources or particular distribution lists where communication takes place. Group owners can accept or deny requests to join or leave the groups they own, thereby ensuring tight control of group membership lists. Exploring the My Access Page When you open the My Access page in Self-Service Manager, you see a summary screen that lists the security and distribution groups (distribution lists) of which you are a member. With a single click, you can remove yourself from a group you select from the list. With another click, you can examine any of the listed groups in detail. By default, the My Access page lists only the groups that are published to Self-Service Manager. It is also possible to have the page list the other groups in which you have membership, not only published groups. Normally, the My Access page lists the groups to which you belong as a direct member. The list can be extended to include all groups of which you are a member, whether directly or indirectly. For example, you might be a direct member of group A which is, in turn, a member of group B. Normally, the list includes only group A, but it is possible to change this behavior so that the list includes both group A and group B. You can remove yourself from only those groups to which you belong as a direct member. For the groups from which you cannot remove yourself, the check box next to the group name is unavailable. You cannot remove yourself from the groups in which you have indirect membership. Likewise, you cannot do this for your primary group. The name of the primary group is displayed in the lower part of the page. The My Access page lists the groups in which you are a regular member and the groups in which you are a temporal member. Regular members remain in the group for an indefinite period of time whereas temporal members are scheduled to be automatically added or removed from the group at a certain point in time. In the list, an icon of a small clock overlays the icon for the groups in which you are a temporal member. It is possible to hide or display the groups to which you are scheduled to be added in the future. The icons identifying such groups are shown in orange. By changing temporal membership settings on a selection of groups, you can choose the time for you to join or leave those groups. You can use the My Access page to join or leave groups. However, your ability to add or remove yourself from a particular group is restricted with your access rights on that group. By default, average users do not have sufficient rights to add or remove themselves from an arbitrary group. To allow users to join or leave a group, group owners or IT administrators have to give the users the appropriate rights. Normally, this is accomplished by publishing the group to Self-Service Manager. The My Access page is mainly intended to enable average users to join or leave published groups. Note that Self-Service Manager obeys all approval rules associated with groups, so your request to join or leave a group may be granted immediately or will be granted when the necessary approvals are performed. 60

61 Feature Guide Open the My Access page: On the ActiveRoles Self-Service Manager Home page, click My Access. Submit a request to join a group: 1. On the ActiveRoles Self-Service Manager Home page, click Request Access. 2. Click Select Groups and then use the Select Groups dialog box to select the group you want to join. Note that the Select Groups dialog box lists only the groups that are published to Self-Service Manager. Keyword Search ActiveRoles Server introduces a new property of groups: keywords. The keywords property on a group can hold multiple string values, which are words or phrases used to identify the group for searching. By using keywords, group owners can optimize search results so as to expose the groups important to self-service users. ActiveRoles Server provides keyword search mechanism to help organize and expose groups. Users can search for groups by the keywords assigned to each group, in addition to other properties such as the group name, type, or description. With the keyword search capability, self-service users can easily find groups even if they do not know or remember the exact group names. Making best use of this search capability requires careful thought and consideration when group owners are publishing groups. It is advisable to enter the keywords most likely to describe each group to someone looking for it. The keyword scheme also lets group owners or IT administrators categorize groups hierarchically. For example, Accounting groups might be further subdivided with keywords such as Accounts Receivable and Payroll. By looking for appropriate keywords, a user can find all groups with the Accounting keyword, or just a subset with the Payroll keyword. Defining Keywords for Groups Users who have read and write access to the Keywords attribute on a group can view, add, remove or change keywords for that group by using the ActiveRoles Server console or Web Interface. In the ActiveRoles Server console, the keywords assigned to a group can be administered: On the General tab in the Properties dialog box for that group In the dialog box displayed by the Publish command on that group In the Web Interface, the keywords assigned to a group can be administered: On the General tab of the General Properties page for that group On the page displayed by the Publish command on that group 61

62 Quest ActiveRoles Server Use the ActiveRoles Server console to view or change the list of the keywords assigned to a group: 1. Open the Properties page for the group and go to the General tab. 2. Click the button next to the Keywords box. 3. Use the Keywords dialog box to view the keywords assigned to the group. You can add, remove, or edit keywords. Searching for Groups by Keyword In Self-Service Manager, users can submit requests to join groups. Keywords help self-service users locate and select groups they want to join. When searching for groups, the Select Object dialog box in Self-Service Manager considers keywords along with group names, so that the search results contain the groups with the names or keywords matching the search string. In addition, the Keywords column provides a way to refine the list of search results by filtering groups with particular keywords. ActiveRoles Server administrators or help-desk technicians can also rely on keywords when searching for groups with the ActiveRoles Server console or Web Interface. In the console, the Find dialog box provides the Keywords search option for the Groups category. Likewise, the Keywords option is available on the Search page for groups, in the Web Interface site for Administrators and in the Web Interface site for Help Desk. Search for groups by keyword in ActiveRoles Self-Service Manager: 1. On the ActiveRoles Self-Service Manager Home page, click My Access. 2. On the My Access page, click Request Access. 3. Use the Select Object dialog box to search for groups: a) In the Name box, type the search string that you want to use to find groups. b) Click the Search button to start the search. The search returns all groups whose name, pre-windows 2000 name, display name, address, or any keyword begins with the specified search string. 4. Refine the list of search results: In the box beneath the Keywords column heading, type a few characters, and then press ENTER. This will filter the list in the Select Object dialog box to display only the groups that have any keyword beginning with the characters you typed. To restore a complete list of groups, point to the area at the top-left corner of the list header and click Show All Objects. Use the ActiveRoles Server console to find all groups in a particular domain that have a certain keyword assigned: 1. Right-click the domain and click Find. 2. In the Find list, click Groups. 3. Click the Group Type tab. 4. In the Keywords box, type the keyword you want to search for. 5. Click Find Now. 62

63 Feature Guide Recycle Bin ActiveRoles Server builds on Active Directory Recycle Bin, a new feature of Active Directory Domain Services in Microsoft Windows Server 2008 R2, to facilitate the restoration of deleted objects. When Recycle Bin is enabled, ActiveRoles Server makes it easy to undo accidental deletions, reducing the time, costs, and user impact associated with the recovery of deleted objects in Active Directory. The use of ActiveRoles Server in conjunction with Active Directory Recycle Bin helps minimize directory service downtime caused by accidental deletions of directory data. Recycle Bin provides the ability to restore deleted objects without using backups or restarting domain controllers and a user interface featured by ActiveRoles Server expedites locating and recovering deleted objects from Recycle Bin. Flexible and powerful mechanisms provided by ActiveRoles Server for administrative tasks delegation, enforcement of policy rules and approvals, and change tracking ensure tight control of the recovery processes. To undo deletions, ActiveRoles Server relies on the ability of Active Directory Recycle Bin to preserve all attributes, including the link-valued attributes, of the deleted objects. This makes it possible to restore deleted objects to the same state they were in immediately before deletion. For example, restored user accounts regain all group memberships that they had at the time of deletion. ActiveRoles Server can be used to restore deleted objects in any managed domain that has Active Directory Recycle Bin enabled. This requires the forest functional level of Windows Server 2008 R2, so all the forest domain controllers must be running Windows Server 2008 R2. In a forest that meets these requirements, an administrator can enable Recycle Bin by using the Active Directory module for Windows PowerShell in Windows Server 2008 R2. For more information about Active Directory Recycle Bin, see What's New in AD DS: Active Directory Recycle Bin ( Once Active Directory Recycle Bin is enabled in a managed domain, ActiveRoles Server provides access to the Deleted Objects container that holds the deleted objects from that domain. In the ActiveRoles Server console tree or in the Web Interface tree view, the container appears at the same level as the domain itself. If multiple managed domains have Active Directory Recycle Bin enabled, then a separate container is displayed for each domain. To tell one container from another, the name of the container includes the domain name (for example, MyDomain.MyCompany.com - Deleted Objects). Use the ActiveRoles Server console to verify whether Active Directory Recycle Bin is enabled in a particular managed domain: Select the Active Directory node in the console tree and examine the details pane. The presence of an object with the name of the domain followed by the Deleted Objects suffix indicates that Active Directory Recycle Bin is enabled in that domain. Note that the Deleted Objects container is displayed only if the access rights of the console user are sufficient to view the contents of the Active Directory container in ActiveRoles Server. Use the ActiveRoles Server console to view both deleted and recycled objects in the Deleted Objects container: On the View menu, click Recycled Objects. If a check mark is present next to the Recycled Objects menu item, the console displays both deleted and recycled objects. To view deleted objects only, click to clear the check mark. 63

64 Quest ActiveRoles Server Restoring Deleted Active Directory Objects The task of restoring deleted objects involves two basic elements: Find and list deleted objects based on the appropriate search conditions Apply the Restore command on a deleted object Find and list deleted objects Search pages in the ActiveRoles Server console or Web Interface facilitate finding deleted objects, enabling the use of very specific queries based on any object properties. It is also possible to examine and search a list of deleted objects that were in a particular Organizational Unit or Managed Unit at the time of deletion. The ActiveRoles Server console offers the Deleted Objects search category in the Find dialog box, which is intended to perform a search in the Deleted Objects container of any managed domain where Active Directory Recycle Bin is enabled. The same option is available on the search pages in the Web Interface. To view and search a list of objects that were deleted from a particular Organizational Unit or Managed Unit, administrators can use the View or Restore Deleted Objects command. The command opens a page that lists the deleted objects that were direct children of the corresponding Organizational Unit or Manager Unit at the time of deletion. In the Web Interface, the list can be sorted or filtered as appropriate to locate particular objects. In the ActiveRoles Server console, the View or Restore Deleted Objects page can be used to search for deleted objects whose name matches a specific search string. It provides flexible matching by using support for ambiguous name resolution. Restore a deleted object For restoring deleted objects ActiveRoles Server offers the Restore command that is available from: A list of search results prepared using the Deleted Objects search category The View or Restore Deleted Objects page A list of objects held in the Deleted Objects container In the ActiveRoles Server console the command can be found on the shortcut menu, which appears when you right-click a deleted object. In the Web Interface, the Restore command is available along with other commands on a menu that appears when you click a deleted object in a list. The Restore command opens a page prompting to choose whether deleted child objects (descendants) of the deleted object should also be restored. This option is selected by default, which ensures that the Restore command applied on a deleted container object restores the entire contents of the container. 64

65 Feature Guide To clarify, consider an example in which an administrator accidentally deletes an Organizational Unit (OU) called Sales_Department that contains a number of user accounts for sales persons along with another OU called Admins that, in turn, contains a user account for an administrative assistant. When applying the Restore command on the Sales_Department OU, with the option to restore child objects, ActiveRoles Server performs the following sequence of steps: 1. Restore the Sales_Department OU 2. Restore all the deleted user accounts that were direct children of the Sales_Department OU 3. Restore the Admins OU in the Sales_Department OU 4. Restore all the deleted user accounts that were direct children of the Admins OU If the option to restore child objects is not selected, ActiveRoles Server performs only the first step, so the restored Sales_Department OU is empty. Use the ActiveRoles Server console to search the Deleted Objects container for deleted objects, and restore an object from the search results list: 1. Right-click the Deleted Objects container you want to search, and then click Find. 2. Verify that the Deleted Objects search category is selected in the Find box. 3. Specify your search conditions and click Find Now. 4. In the list of search results, right-click an object to un-delete, and then click Restore. Use the ActiveRoles Server console to search for objects that were deleted from a particular organizational unit, and restore an object from the search results list: 1. Right-click the organizational unit and click View or Restore Deleted Objects. Note that this command is not displayed unless Active Directory Recycle Bin is enabled in the domain that holds the organizational unit. 2. In the View or Restore Deleted Objects dialog box, find and select the object to restore, and then click the Restore button. Use the Find command in the ActiveRoles Server console to search an object for its deleted child objects, and restore a child object form the search results list: 1. Right-click the Deleted Objects container you want to search, and then click Find. 2. Verify that the Deleted Objects search category is selected in the Find box. 3. Click the button next to the Deleted from box, and select the object to search for deleted children. 4. Specify other search conditions as needed, and then click Find Now. 5. In the list of search results, right-click an object to un-delete, and then click Restore. The ability to find deleted children of any object is helpful in a situation where you need to selectively restore child objects after you have restored their parent object. For example, you might need to restore a deleted user or computer object alone and then restore select child objects of that object. 65

66 Quest ActiveRoles Server Delegating Operations on Deleted Objects The delegation model based on the ActiveRoles Server Access Templates is fully applicable to the administrative tasks specific to deleted objects. A new Access Template called All Objects - View or Restore Deleted Objects makes it easy to delegate the following operations to selected users: Viewing deleted Active Directory objects Restoring a deleted Active Directory object When applied to the Deleted Objects container, the Access Template gives the delegated users the right to view and restore any deleted object. With the Access Template applied to an Organizational Unit (OU) or a Managed Unit (MU), the delegated users are given the right to view and restore only those deleted objects that were located in that OU or MU at the time of deletion. Use the ActiveRoles Server console to delegate the task of restoring deleted objects: 1. In the console tree, expand Configuration Access Templates, and select Active Directory under Access Templates. 2. In the details pane, right-click All Objects - View or Restore Deleted Objects, and click Links. 3. Click Add in the Links window, and follow the instructions in the Delegation of Control wizard to apply the Access Template. Applying Policy or Workflow Rules on Deleted Objects In addition to the delegation of administrative tasks, ActiveRoles Server provides the ability to establish policy-based control over the process of restoring deleted objects. Policy rules can be used to perform additional verifications or custom script-based actions upon the restoration of deleted objects. Workflow rules can be applied so as to require approval for the restore operation or notify of the restore operation completion via . The policy or workflow rules to control the process of restoring or otherwise managing deleted objects can be defined on: The Active Directory node in the ActiveRoles Server console - The rules defined in this way affect all deleted objects in any managed domain that has ActiveRoles Server Recycle Bin enabled. The node representing a domain or the Deleted Objects container for that domain in the ActiveRoles Server console - These rules affect all deleted objects in that domain only. An Organizational Unit (OU) or Managed Unit (MU) that held the object at the time of deletion - Although the deleted object no longer belongs to that OU or MU, ActiveRoles Server considers the former location of the object so that the rules applied on that location continue to affect the object after the deletion. For example, an administrator could create a workflow to require approval for the restoration of any user account that was deleted from a certain Organizational Unit (OU). The workflow definition would contain an appropriate approval rule, and have that OU specified as the target container in the workflow start conditions. 66

67 Feature Guide Use the ActiveRoles Server console to configure an approval workflow such that restoring user accounts deleted from a particular organizational unit requires approval by the manager of that organizational unit: 1. Create a workflow definition and add an approval activity to it. 2. Set the properties of the approval activity as follows: On the Approvers page, click Designate Approvers, and then select the Manager of organizational unit where operation target object is located check box. 3. Configure the workflow start conditions as follows: Choose User as the target object type and Restore as the operation that starts the workflow. Configure the Initiator Conditions list to contain a single entry, with Initiator set to Any User and Container set to the organizational unit in question. 4. Save your changes to the workflow definition. Support for Special-purpose Mailbox Types ActiveRoles Server now provides a graphical user interface for creating mailboxes of these types that are available in Exchange Server 2007 or later: User mailbox This is the most commonly used mailbox type, and it is typically the mailbox type that is assigned to users in an Exchange organization. You could create user mailboxes with earlier versions of ActiveRoles Server. Room mailbox Mailboxes of this type are assigned to meeting locations, such as conference rooms, and can be included as resources in meeting requests. Equipment mailbox Mailboxes of this type are assigned to non-location specific resources, and can be included along with room mailboxes in meeting requests. Linked mailbox Mailboxes of this type are accessed by users in a separate, trusted forest. Linked mailboxes may be necessary for organizations that choose to deploy Exchange in a resource forest. Shared mailbox Mailboxes of this type are not primarily assigned to individual users. A shared mailbox is normally configured to allow full access for multiple users. Creating a Mailbox Both the ActiveRoles Server console and Web Interface provides the ability to create mailboxes. Creating a mailbox is accomplished through the creation of a new user account or by associating an existing user account with a new mailbox. Each mailbox consists of a user account that resides in an Active Directory domain and the mailbox data that is stored in a mailbox database. All configuration data for the mailbox is stored in the Exchange attributes of the user account. The mailbox database contains the actual data that is in the mailbox associated with the user account. To create a mailbox by using ActiveRoles Server, you choose the appropriate command either on a container such as an organizational unit (this creates a new user account to be associated with the mailbox) or on an existing user account (this causes the new mailbox to be associated with that user account). The container or the existing user account must be from a domain that belongs to the Active Directory forest where your Exchange organization is deployed. 67

68 Quest ActiveRoles Server Creating a new user account along with a mailbox In the managed domains that belong to the Exchange organization, the default behavior of the command for creating a user is to create a new user account along with a user mailbox associated with that user account. The user creation wizard provides the option to skip the creation of a user mailbox. For the mailbox types other than user mailbox, ActiveRoles Server provides separate commands on container objects. Each of those commands effectively creates a new, disabled user account and associates a mailbox of the corresponding type with that account. Use the ActiveRoles Server console to create a new user mailbox: 1. Right-click an organizational unit and select New User. 2. Follow the wizard pages. Ensure that the Create an Exchange mailbox option is selected on the wizard page that prompts you for the user alias and mailbox location. Use the ActiveRoles Server console to create a new special-purpose mailbox: 1. Right-click an organizational unit, point to New, and then click one of the following: Click Room Mailbox to create a room mailbox. Click Equipment Mailbox to create an equipment mailbox. Click Linked Mailbox to create a linked mailbox. Click Shared Mailbox to create a shared mailbox. 2. Follow the wizard pages. Similar commands are available on organizational units and other containers in the Web Interface. Creating a mailbox for an existing user account For a user account that is not associated with a mailbox, ActiveRoles Server can be used to create a mailbox. By applying the appropriate command on such an account, you can create a mailbox that will be associated with that account. This must be a disabled account if you want to create a mailbox type other than user mailbox. Use the ActiveRoles Server console to create a mailbox for an existing user account: 1. Right-click the user account and select Exchange Tasks. 2. Follow the wizard pages. On the Available Tasks page, click one of the following: Click Create User Mailbox to create a user mailbox. Click Create Room Mailbox to create a room mailbox. Click Create Equipment Mailbox to create an equipment mailbox. Click Create Linked Mailbox to create a linked mailbox. Click Create Shared Mailbox to create a shared mailbox. Only the Create User Mailbox command is available if the user account is not disabled. 3. Follow the wizard pages to complete the creation of the mailbox. The same commands are available on user accounts in the Web Interface. 68

69 Feature Guide Searching for Mailboxes The ActiveRoles Server console can be used to search for user accounts that are associated with mailboxes of a certain type. This allows you to easily locate the mailboxes you want to administer. To view or change mailbox configuration properties, you can simply double-click a user account in the list of search results. Use the ActiveRoles Server console to search for mailboxes: 1. Right-click the organizational unit or domain that holds the user accounts associated with the mailboxes to search for, and then click Find. 2. From the Find list, select Exchange Recipients. 3. On the General tab, select the appropriate check box to indicate the mailbox type you want to search for. 4. Use the Storage or Advanced tab to specify any additional search conditions, if necessary, and then click Find Now. For example, to find only room mailboxes, clear all check boxes on the General tab, except for the Room mailboxes check box. Administering Mailboxes All configuration data for a mailbox is stored in the Exchange attributes of the user account associated with that mailbox. The ActiveRoles Server console provides the ability to view or modify the Exchange attributes by exposing the user management pages that are specific to those attributes: The Resource Information page is intended to view or change the resource mailbox settings such as the resource capacity and the resource custom properties. This page is available only for room and equipment mailboxes. The Master Account page is intended to view or change the linked master account the user account from a trusted forest that is used to access the linked mailbox. This page is available only for linked mailboxes. The Mailbox Sharing page is intended to view, add or remove the users who can log on to the shared mailbox and have full access to that mailbox. This page is available only for shared mailboxes. The Exchange General page can be used to set delivery restrictions, delivery options, and storage limits. From this page, it is also possible to view the mailbox type, the mailbox store or database that holds the mailbox data, and view or modify the user s alias. The Exchange Advanced page can be used to select a simple display name, hide the user from the address lists, downgrade high priority bound for X.400, assign custom attributes, select Internet Locator Service (ILS) settings, and configure mailbox rights. The Addresses page can be used to view, add, modify, or remove addresses. From this page, it is also possible to select a primary address when the user has two or more addresses of the same address type. The Exchange Features page can be used to enable, disable, or configure a variety of mailbox features, such as Outlook Mobile Access, Exchange ActiveSync, Up-to-date Notifications, POP3, IMAP4, Outlook Web Access, and MAPI. Similar pages are also available on the mailbox user accounts in the ActiveRoles Server Web Interface. 69

70 Quest ActiveRoles Server Use the ActiveRoles Server console to view or change mailbox configuration properties: Double-click the user account that is associated with the mailbox, and then go to the appropriate tab in the Properties dialog box. For example, if the user account is associated with a room or equipment mailbox, the Properties dialog box includes the Resource Information tab. If the user account is associated with a linked or shared mailbox, the Master Account or Mailbox Sharing tab appears in the Properties dialog box. Support for Exchange Server 2010 ActiveRoles Server now supports the Exchange recipient management tasks for the earlier versions of Microsoft Exchange Server and Exchange Server 2010 alike. ActiveRoles Server helps you streamline and secure your administration of Exchange Server 2010, through the use of role-based delegation, policy-based administration, flexible administrative views, and comprehensive console and Web-based interfaces to perform recipient management tasks. Managing Exchange recipients You can perform recipient management tasks using both the ActiveRoles Server console and the Web Interface. These interfaces support Exchange tasks on mailboxes, mail users and contacts, mail-enabled security and distribution groups, and dynamic (query-based) distribution groups, so you can create, view, and modify Exchange recipients on Exchange Server 2010 the same way you do with earlier versions of Exchange Server. Delegating recipient management tasks The ActiveRoles Server delegation model is fully applicable to the management tasks on Exchange Server 2010 recipients. A rich suite of Exchange-specific Access Templates, available out of the box, makes it easy to delegate the management of recipient properties, the use of the Exchange Tasks Wizard, and the management of message settings. Also provided are Access Templates that specify access to individual Exchange-related properties of users, groups, and contacts. Auto-provisioning of Exchange mailboxes The provisioning policies included with ActiveRoles Server enable automation of Exchange mailbox creation and management. Exchange Mailbox AutoProvisioning policies can be configured to ensure that mailboxes are created in appropriate mailbox databases, including those of Exchange Server Alias Generation policies can be used to automatically assign appropriate aliases when provisioning mailboxes. Auto-provisioning of Exchange distribution lists The Group Family feature of ActiveRoles Server automates the creation of security and distribution groups, including mail-enabled groups or distribution lists. Group Family automatically creates groups and maintains group membership lists in compliance with configurable rules, allowing group membership to be defined as a function of recipient properties in the directory. Group Family also allows for creation of new groups based on new values encountered in recipient properties. 70

71 Feature Guide De-provisioning of user mailboxes The deprovisioning policies included with ActiveRoles Server can be used to automate revocation of user access to Exchange resources on Exchange Server 2010 as well as on earlier versions of Exchange Server. Exchange Mailbox Deprovisioning policies can be configured so that deprovisioning a user causes ActiveRoles Server to make all the necessary changes to deprovision the Exchange resources for that user, such as removing the mailbox from the Global Address List, providing designated persons with access to the mailbox, and adjusting the message forwarding settings on the mailbox. Exchange resource forest management An optional add-on application for ActiveRoles Server, ActiveRoles Exchange Resource Forest Manager provides synchronized provisioning and a single console for management of user and mailbox attributes even when mailboxes and user accounts are in separate forests. When extended with Exchange Resource Forest Manager, ActiveRoles Server provides unified user and mailbox management, improves security, saves time and reduces costs by automating the provisioning and synchronization processes in Exchange organizations that use the resource forest topology. Search by Multiple Names when Selecting Objects in the Web Interface The Select Object dialog box in the Web Interface now supports a search for objects that match any name in a list of object names. If you know names of objects to select, you can type in the names and then have the dialog box list the objects matching those names. This feature makes it easier to select the objects you want. Use the Web Interface to add several users to a certain group: 1. Find and select the group; then, choose the Members command. 2. On the Members page, click Add to open the Select Object dialog box. 3. In the Name box, enter a semicolon-separated list of names of the users to be added to the group, and then click the Search button next to the Name box. 4. In the list of search results, click each of the names of the users you want to add to the group, and then click OK. Documenting the Reason for a Change Request When ActiveRoles Server users request changes that require approval, they are now prompted to specify a reason for the changes. A dialog box appears upon an attempt to commit the changes, allowing the user to type a reason text. The user cannot submit the changes for approval without providing a reason. When the changes are submitted for approval, the reason text appears in the approval tasks presented to the approvers in the Web Interface, which makes it easier for approvers to decide whether the changes should be allowed. The reason text is also included in the approval notification messages and in the change history reports. By requiring users to enter a reason text, ActiveRoles Server provides a way to consistently document and track the reasons for requesting changes. 71

72 Quest ActiveRoles Server Use the ActiveRoles Server console to publish a group to Self-Service Manager: 1. Ensure that the group has a manager assigned to it: a) Open the Properties dialog box for the group and go to the Managed By tab. b) If the Name box is empty on the Managed By tab, click Change and then select a user account to hold the manager role for the group. 2. Right-click the group and click Publish. 3. Select the Approval by the primary owner (manager) of the group check box, and then click the Publish button. Use Self-Service Manager to submit a request to join the group you have published: 1. Log on with a user account that is not a member of the AR Server Admin role. If you log on as AR Server Admin, the changes you make using ActiveRoles Server will not require approval, so you will not be prompted to specify a reason for your change request. 2. On the My Access page in Self-Service Manager, click Request Access. 3. In the Select Object dialog box, click the group you have published, and then click OK. 4. In the dialog box informing that your changes will be submitted for approval, type a reason text, and then click OK. 72

73 Feature Guide Configuring and Administering ActiveRoles Server This section summarizes the features and enhancements that improve the user experience of those who manage ActiveRoles Server, implementing and maintaining the ActiveRoles Server-based administrative structure. Support for Microsoft SQL Server 2008 ActiveRoles Server now supports Microsoft SQL Server 2008, to take advantage of high availability, industry-leading performance, improved security, and other significant enhancements engineered into this new technology from Microsoft. SQL Server 2005 is also supported, which gives organizations the flexibility to maintain ActiveRoles Server data repositories using the database platform of their choice. The benefits you gain by choosing SQL Server 2008 as the database platform for ActiveRoles Server include: Increased availability Enhanced database mirroring can help ensure uninterrupted operation of the core ActiveRoles Server components that rely on the database availability. Increased responsiveness High-performance query-processing engine enables faster access to the database, which can increase responsiveness of ActiveRoles Server in certain scenarios. Improved security Enhanced cryptographic capabilities and support for enterprise key management solutions can help ensure that sensitive ActiveRoles Server data, such as rights assignments, is not compromised. Any edition of SQL Server 2008 can be used as a database or reporting services platform for ActiveRoles Server, with the limitation that ActiveRoles Server replication publishing is not available with SQL Server Express. Support for Database Mirroring Beginning with the 6.5 release, ActiveRoles Server can use the Microsoft SQL Server database mirroring technology to improve the availability of the Administration Service. Database mirroring provides a standby database server that supports failover. Once the current database server fails, the Administration Service can recover quickly by automatically reconnecting to the standby server. Database mirroring increases database availability by supporting rapid failover. This technology can be used to maintain two copies of a single ActiveRoles Server database on different server instances of SQL Server Database Engine. One server instance serves the database to the Administration Service; this instance is referred to as the principal server. The other instance acts as a standby server; this instance is referred to as the mirror server. 73

74 Quest ActiveRoles Server Role Switching Within the context of database mirroring, the mirror server acts as the failover partner for the principal server. In the event of a disaster, the mirror server takes over the role of the principal server, bringing the mirror copy of the database online as the new principal database. The former principal server, if available, then assumes the role of the mirror server. This process, known as role switching, can take the form of: Automatic failover If the principal server becomes unavailable, quickly brings the mirror copy of the database online as the new principal database. Manual failover Allows the database owner to reverse the roles of the failover partners, if necessary. Forced service If the principal server becomes unavailable, allows the database owner to restore access to the database by forcing the mirror server to take over the role of the principal server. In any role-switching scenario, as soon as the new principal database comes online, the Administration Service can recover by automatically reconnecting to the database. For more information about the database mirroring technology, and instructions on how to set up and administer database mirroring on SQL Server, see the Database Mirroring topics in the SQL Server product documentation at The ActiveRoles Server replication function is not supported for the databases that have mirroring set up. If you attempt to perform the Promote to Publisher or Add Subscriber operation on such a database, you receive an error. Here we assume that mirroring for the database of ActiveRoles Server is already set up on the SQL Server side in accord with the recommendations and instructions found in Microsoft's documentation, so that the following conditions are fulfilled: The Administration Service is connected to the Configuration database on the principal database server. Replication is not configured for the Configuration database (the database server acts as a stand-alone server as applied to ActiveRoles Server replication). The Administration Service is connected to the Management History database on the principal database server (by default, the Management History database is the same as the Configuration database). Replication is not configured for the Management History database (the database server acts as a stand-alone server as applied to ActiveRoles Server replication). 74

75 Feature Guide Under these conditions, the Administration Service can be instructed to automatically connect to the new principal database in the event of database server role switching. On the computer running the Administration Service, add a string value to each of these two registry keys, and then restart the Administration Service: Key: HKLM\SOFTWARE\Aelita\Enterprise Directory Manager\DatabaseConnectionString\ Value Name: Failover Partner Value Data: <Identifies the SQL Server instance that currently owns the mirror server role for the Configuration database> Key: HKLM\SOFTWARE\Aelita\Enterprise Directory Manager\CHDatabaseConnectionString\ Value Name: Failover Partner Value Data: <Identifies the SQL Server instance that currently owns the mirror server role for the Management History database> If the default instance is used, the value data is the NetBIOS name of the computer running SQL Server. Otherwise, the value data is the NetBIOS name of the computer, followed by a backslash, followed by the name of the instance (such as ComputerName\InstanceName). By default, the same database is used for the Configuration and Management History data; therefore, the value data would be the same in the DatabaseConnectionString and CHDatabaseConnectionString keys. In the ActiveRoles Server console, you can view the mirroring status of the Configuration or Management History database that is used by a particular instance of the Administration Service: 1. In the console tree, select Configuration Server Configuration Administration Services. 2. In the details pane, double-click the name of the Administration Service whose database you want to examine. 3. In the Properties dialog box, click the Configuration Database or Management History Database tab, and observe the information in the Database mirroring area: Role Current role of the database in the database mirroring session (Principal or Mirror). Partner The instance name and computer name for the other partner in the database mirroring session. State Current state of the mirrored database and of the database mirroring session. For more information about this field, see the Mirroring States topic at If no information is displayed in the Database Mirroring area, then database mirroring is not configured. You can also view the mirroring status of a Configuration database or a Management History database on the General tab in the Properties dialog box for the object representing that database in the Configuration/Server Configuration/Configuration Databases or Configuration/Server Configuration/Management History Databases container, respectively. 75

76 Quest ActiveRoles Server Enhanced Support for Exchange Server 2007 ActiveRoles Server no longer requires that the Administration Service use the service account (rather than an override account) to access the domains that hold Exchange recipients when performing Exchange tasks in an Exchange Server 2007 organization. For the Move Mailbox task, the use of the service account is still required. Suppose you want to create a user account with a mailbox on Exchange Server To perform this task, earlier versions of ActiveRoles Server required that the domain to hold the user account be registered with ActiveRoles Server so that the service account of the Administration Service is used to access the domain. The latest version removes this limitation, allowing an override account to be used to access the domain. The use of an override account provides a number of benefits in complex Active Directory environments where multiple instances of the Administration Service are deployed. Namely, with an override account, every Administration Service instance uses that same account to access the domain. As a result, behavior of ActiveRoles Server remains the same regardless of which Administration Service instance performs a particular task. With the service account, each instance of the Administration Service uses its own account. Since different service accounts may have different access permissions in the domain, a task successfully performed by one of the instances may fail to be performed by another one. The use of an override account assures smooth operation of ActiveRoles Server when switching between Administration Service instances occurs. In addition, in a multi-domain or multi-forest environment, it may not be feasible to give the service account the necessary access permissions in every domain. This problem can be addressed by using individual override accounts on a per-domain basis. To perform Exchange tasks in an Exchange Server 2007 organization, the latest version of ActiveRoles Server requires the following conditions to be fulfilled regardless of whether the service account or an override account is used: The Administration Service that performs the tasks is running in the Active Directory forest in which the Exchange Organization is deployed. On the computer running the Administration Service, the Exchange Server 2007 management tools are installed and updated with Exchange Server 2007 Service Pack 2 or later. If you want ActiveRoles Server to perform the Move Mailbox task, do not use an override account when registering domains with ActiveRoles Server. In this scenario, a domain must be registered with the option to access the domain using the service account information. Refer to the Exchange Server 2007 subsection of the Access to Exchange Organization section in the ActiveRoles Server Quick Start Guide. 76

77 Feature Guide Preserving ActiveRoles Server Data on Deleted Objects When you use an earlier version of ActiveRoles Server to delete an Active Directory object, such as a user or group, the data specific to ActiveRoles Server is immediately and permanently removed from the object. This data includes the values of any custom stored virtual attributes on the object as well as the Access Template and Policy Object links that pointed directly to the object at the time of deletion. If an object is accidentally deleted and then restored from an Active Directory backup, all the object data is restored in Active Directory, but the ActiveRoles Server specific data is not restored. With the earlier versions of ActiveRoles Server, administrators did not have a solution that would help them recover a deleted object in its entirety, so that the state of the object in ActiveRoles Server would be restored to the point in time when the deletion occurred. In the latest version of ActiveRoles Server, the behavior of object deletion has changed. When you delete an object, the ActiveRoles Server specific data is not removed from the object. Instead, the values of the custom stored virtual attributes on the object, as well as the links, are retained in the ActiveRoles Server database. You can restore the object in Active Directory and be sure that the restored object has the same logical state in ActiveRoles Server as it had immediately before deletion. How you can restore a deleted object in Active Directory depends on whether Active Directory Recycle Bin is enabled in the domain containing the object. Without Recycle Bin, the only way to restore a deleted object along with all of its attributes and links in Active Directory is to use an Active Directory backup. For example, Quest Recovery Manager for Active Directory provides the ability to restore deleted objects in that way. With Recycle Bin enabled in Active Directory, ActiveRoles Server can now be used to restore deleted objects (see the Recycle Bin section in this document). In both cases, ActiveRoles Server ensures that not only the Active Directory attributes and links but also the ActiveRoles Server attributes and links are restored on the object. A deleted object can be restored in Active Directory unless the object is physically deleted (garbage-collected) in a domain that does not have Active Directory Recycle Bin or recycled in a domain that has Recycle Bin enabled. For this reason, ActiveRoles Server removes the ActiveRoles Server data from the deleted objects that can no longer be restored in Active Directory. A scheduled task called Deleted Objects Cleanup removes all ActiveRoles Server related data from objects that were deleted and then garbage-collected or recycled in any of the managed Active Directory domains. For each of those objects, it deletes all attributes and links that exist on the object in ActiveRoles Server. Note that this data is not removed when the object is deleted, so as to enable the restoration of the object. The data is removed only after the object is garbage-collected or recycled. One more function of the Deleted Objects Cleanup task is to restore the Access Template and Policy Object links after a deleted object has been restored. When an object is deleted, all the links that directly point to that object are disabled in ActiveRoles Server. If the task detects that the object is restored, it enables the links. Since the task normally runs one time a day, a noticeable delay in restoring the links may occur in ActiveRoles Server after the object is restored in Active Directory. Use the ActiveRoles Server console to view or change the schedule of the Deleted Objects Cleanup task: 1. Select the Configuration/Server Configuration/Scheduled Tasks/Builtin container in the console tree, and then double-click Deleted Objects Cleanup in the details pane. 2. Click the Schedule tab in the Deleted Objects Cleanup Properties dialog box. By default, the task is scheduled to run one time a day in the early morning. It is advisable not to change this schedule since the task is resource-intensive and it may require considerable time to complete. 77

78 Quest ActiveRoles Server Use the ActiveRoles Server console to run the Deleted Objects Cleanup task immediately: Right-click Deleted Objects Cleanup in the details pane, point to All Tasks, and then click Execute. Default Retention Time for Change History Increased The Management History data store in ActiveRoles Server includes the Change Tracking log that holds history information about requests to change directory data, one record per request. Each record contains information on the changes to a certain object that were made in accordance with a certain change request. ActiveRoles Server uses information held in the Change Tracking log to build reports regarding change history and user activity. The more change requests are retained in the log, the more changes to directory data are covered by the reports. By default, the Change Tracking log is now configured to retain information about requests that occurred within last 30 days (the earlier versions of ActiveRoles Server had the default setting of 7 days). Information about change requests is written to the log so that new requests replace those that are older than 30 days. If you increase this number, do it carefully. Increasing this number significantly increases the size of the log. Use the ActiveRoles Server console to view or modify the Change Tracking log settings: In the console tree, select Configuration Server Configuration, and then double-click the Change Tracking Log Configuration object in the details pane. Prior to changing the Change Tracking log settings, it is advisable to review the Considerations and Best Practices section of the Management History chapter in the ActiveRoles Server Administrator Guide. Installing a Separate Management History Database When installing the Administration Service, you now have the option to specify a separate database for storing Management History data. This installation option is intended to support advanced deployment scenarios where it is impractical to use the same database for both Management History data and Configuration data. The use of a separate Management History database could be justified by reducing replication traffic when multiple Administration Service instances synchronize their configuration data via ActiveRoles Server replication, or by reducing database size when multiple Administration Service instances share the same Configuration database. It is important to note that multiple Administration Service instances can be configured to share common Management History data only if they share common configuration data. Data sharing may be achieved by means of ActiveRoles Server replication or by having multiple Administration Service instances use the same Configuration or Management History database. For example, if you want two instances of the Administration Service to use the same Management History database, you have to ensure that any one of these conditions is fulfilled: (1) both instances use the same Configuration database or (2) if each of the two instances uses its own Configuration databases, the two databases are synchronized by using ActiveRoles Server replication; otherwise, the Administration Service will fail to start. 78

79 Feature Guide The Management History data includes: Information about the changes to directory data that were made by ActiveRoles Server users. This information is used to prepare the Change History and User Activity reports. Information about the approval, attestation, temporal group membership, and deprovisioning tasks. This information is used by the ActiveRoles Server features such as Approval Workflow, Attestation Review, Temporal Group Memberships, and Undo Deprovisioning. Many important features and functions of ActiveRoles Server heavily rely on consistency and availability of Management History data. With multiple Administration Service instances of common configuration, it is highly advisable for the Administration Service instances to share the same Management History data. The default installation of the Administration Service meets this requirement by using a single database to store both Configuration data and Management History data. However, if you decide to separate the Management History data store from the Configuration data store, you can do this when installing the Administration Service: the option to store Management History in a separate database is available on the Database and Connection Settings page in the Administration Service Installation Wizard. The behavior of the option depends upon whether you choose to create a new database or use an existing database for the Administration Service you are installing. Creating a New Database The Administration Service Setup program creates a new Configuration database in the following deployment scenarios: Installation of the new Administration Service instance on a clean computer. Upgrade of the Administration Service instance that uses the database of an earlier schema version. In both scenarios, the Installation Wizard provides the option to create a separate Management History database. By default, that option is not selected with the first scenario: we recommend that the same database be used to hold both Configuration and Management History data. As for the second scenario, the Setup program checks to see whether the Administration Service instance you are upgrading is already configured to use a separate Management History database. If so, the option is selected by default; otherwise, the option is not selected. During the upgrade, the Installation Wizard creates a new Configuration database and, if the option to use a separate Management History database is selected, it also creates a new Management History database. The default behavior of the Installation Wizard in this scenario is to import the existing configuration data to the new Configuration database. However, the existing Management History data is not imported during the upgrade. You have to use the Management History Migration Wizard to import the Management History data after the upgrade. The data should be imported to the database you chose to store Management History: the database that also stores Configuration data or a separate database. For more information and instructions, see the Importing Management History Data section in the ActiveRoles Server Quick Start Guide. 79

80 Quest ActiveRoles Server Using an Existing Database Another deployment scenario that involves the use of a separate Management History database is as follows: You already have an Administration Service instance deployed that stores Management History in a separate database. You want to install an additional Administration Service instance and configure the new instance to use the same Management History database as the existing instance. In this scenario, when installing the new Administration Service, you select the corresponding option on the Database and Connection Settings page in the Installation Wizard, and then specify the location and the name of the Management History database that is used by the existing instance of the Administration Service. With this scenario, you configure two instances of the Administration Service to use the same Management History database, so you need to ensure that both instances have the same configuration data. When installing the additional Administration Service instance, choose the option to share common configuration database. For more information and instructions on how to separate the Management History data store from the Configuration data store, see the Replication of Management History Data and Centralized Management History Storage sections in the ActiveRoles Server Administrator Guide. Use the following steps to upgrade an Administration Service instance of an earlier version in the situation where the instance is configured to use a separate Management History database. 1. Ensure that the Administration Service instance you are going to upgrade does not participate in ActiveRoles Server replication: a) In the ActiveRoles Server console connected to that Administration Service instance, and inspect the contents of the Configuration/Server Configuration/Configuration Databases container to verify that the replication role of the database server is Standalone. b) If the database server has the replication role of Subscriber, connect to the Publisher Administration Service and delete that Subscriber from the Configuration Databases container. c) If the database server has the replication role of Publisher, delete all the Subscribers from the Configuration Databases container and then run the Demote command on the Publisher in that container. 2. Start the Administration Service Setup program from the ActiveRoles Server page in the ActiveRoles Server CD Autorun window (click the corresponding link on that page). 3. Follow the steps in the Installation Wizard until you reach the Database and Connection Settings step. 4. Verify the settings on the Database and Connection Settings page to ensure that the Store Management History in a separate database check box is selected, and then click Next. 80

81 Feature Guide 5. On the Management History Database page, specify the location and name of the database to be used for storing Management History by the Administration Service after the upgrade. This cannot be the database that is used by the Administration Service instance you are upgrading. Setup needs to create a new database since the existing one is incompatible with the new version of ActiveRoles Server. 6. Follow the steps in the Installation Wizard to complete the upgrade. During the upgrade, the Setup program imports the Configuration data from the database of the earlier version. To import the Management History data, use the Management History Migration Wizard after the upgrade of the Administration Service is completed. Separate License for Self-Service Manager ActiveRoles Server ships with ActiveRoles Self-Service Manager, an optional add-on module that enables application and data owners to self-manage their groups. Self-Service Manager now requires a separate license, in addition to the ActiveRoles Server license. You need to purchase and install a license for Self-Service Manager if you want to use the following features: Attestation Review Involves the use of the ActiveRoles Server console to configure and run periodic reviews of group membership lists. Group Management Self-Service Involves the use of the My Groups, My Reviews, and My Access pages in Self-Service Manager. You can install your license for Self-Service Manager when installing the Administration Service or after the Administration Service and the ActiveRoles Server console are installed. The ActiveRoles Server console can be used to view the information about the licenses that are installed, and it allows you to install a new license. You can deploy ActiveRoles Server without installing a license for Self-Service Manager. In this case, you will receive a warning message that informs of a license violation whenever you attempt to use any of the features that require a license for Self-Service Manager. With earlier versions of ActiveRoles Server, a special option in the ActiveRoles Server license was required to license Self-Service Manager. Although the license for version 6.0 or 6.1 allows the upgrade to version 6.5, the Self-Service Manager option in such a license is not valid for the new version of Self-Service Manager. When upgrading to version 6.5, you will need to install a new license for Self-Service Manager even though your ActiveRoles Server license includes that option. Contact your Quest Software representative to obtain a license for ActiveRoles Self-Service Manager. Install a license for Self-Service Manager when installing the Administration Service: 1. Follow the steps in the Administration Service Installation Wizard until you reach the Select Features step. 2. On the Select Features page, do the following: a) Ensure that the ActiveRoles Self-Service Manager feature is selected for installation. b) Click the Licenses button. c) In the License Manager dialog box, click ActiveRoles Self-Service Manager, and then click Browse License. d) Use the Open dialog box to locate and open your license file for Self-Service Manager. 81

82 Quest ActiveRoles Server e) Click Close in the License Manager dialog box. f) Click Next. 3. Follow the wizard steps to complete the installation. Install a license for Self-Service Manager by using the ActiveRoles Server console: 1. Right-click the console tree root, click About, and then click View or update Self-Service Manager license. 2. Click the Update License button, and then use the Open dialog box to locate and open your license file for ActiveRoles Self-Service Manager. FIPS Compliant Encryption ActiveRoles Server now employs only the FIPS compliant cryptographic algorithms and modules provided by Microsoft. This ensures the correct operation of ActiveRoles Server in environments that require the use of FIPS compliant algorithms for encryption, cashing and signing. The Federal Information Processing Standard (FIPS) is a security implementation designed for certifying cryptographic software. The use of FIPS validated encryption is required by the U.S. Government and requested by other prominent institutions. Configure Group Policy in your Active Directory environment to enable the following security setting on all computers running the ActiveRoles Server components: System cryptography: Use FIPS compliant algorithms for encryption, hashing and signing. You can configure this security setting by opening the appropriate Group Policy object and expanding the console tree as such: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\. For specific instructions on how to configure security policy settings, see Microsoft s article Edit security settings on a Group Policy object at 82