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 legal@quest.com 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