Design and Deployment Guide for Self-Service Distribution Group Management
Applies To: Forefront Identity Manager 2010
This document outlines the deployment steps for one of the primary scenarios for Microsoft® Forefront® Identity Manager (FIM) 2010: self-service distribution group (DG) management. The examples shown feature a fictional company, Fabrikam.
What This Document Covers
This document provides a conceptual framework and an example strategy to help you deploy self-service DG management.
For an overview of FIM 2010 documentation and guidance for using it, see the Documentation Roadmap.
Prerequisite Knowledge
This document assumes that you have a basic understanding of FIM 2010 and are familiar with the installation procedures.
Audience
This document is intended for system administrators and information technology (IT) personnel who plan to deploy FIM 2010 for group management scenarios.
Getting Support
If you have questions regarding the content of this document or if you have general feedback you would like to discuss, feel free to post a message to the Microsoft Forefront Identity Manager Discussion forum (https://go.microsoft.com/fwlink/?LinkId=163230).
Planning the FIM 2010 Deployment
Fabrikam is a large company that uses Microsoft Exchange Server as its e-mail service, providing more than 20,000 employees with Exchange Server DG functionality. Fabrikam has more than 5,000 DGs that they use to facilitate collaboration on various projects and processes. Fabrikam has outsourced their helpdesk support, including support for the creation and management of Exchange Server DGs. Internal analysis has shown that support for DGs is one of the largest contributors to the cost of the helpdesk service. Furthermore, end users have expressed dissatisfaction with the amount of time it takes for their helpdesk to complete certain requests.
Fabrikam wants to achieve two key goals for using FIM 2010:
Reduce support costs
Provide users with more control over creating, joining, and leaving groups
In accordance with their best practice processes, Fabrikam plans a phased deployment beginning with the Human Resources (HR) department. This plan consists of the procedures outlined in this document and includes a test plan preceding the final deployment into a production environment. The plan concludes with an expansion of the deployment to the remainder of the company.
Installing FIM 2010 in a Preproduction Environment
Following best practices, Fabrikam wants to deploy FIM in a preproduction environment so that it can validate the correct configuration to meet its goals without affecting the production environment.
Fabrikam decides to implement a four-server topology to meet its needs:
FIM Portal and Service for user requests
FIM Portal and Service for administration and synchronization
FIM Service database
FIM Synchronization Service and Synchronization Service database
This topology is represented in the following diagram:
.gif "Sample topology for deploying group management")
Fabrikam first identifies the server hardware characteristics needed to run FIM in the production environment. Then, they identify similar servers in their preproduction environment. Fabrikam installs the appropriate FIM 2010 components on each of the servers.
For more information about the recommended configuration during the setup of the FIM Service, see the Installation Guide. For more information about capacity planning for FIM, see the Capacity Planning Guide.
Determining Active Directory Objects to Represent in FIM
Fabrikam begins its deployment by designating the objects that need to be represented in FIM 2010. FIM 2010 must have representations for each of these objects:
Targeted users
DGs owned by targeted users
Any objects that are members of the DGs owned by targeted users
Any objects in Active Directory® Domain Services (AD DS) that targeted users might need to include in DGs created later
To achieve this, Fabrikam decides to sync all users, contacts, and mail-enabled groups from AD DS to FIM. They do not sync conference rooms or service accounts because these are not part of the DGs at Fabrikam. At a conceptual level, administrators need to configure properties to make these objects usable within FIM 2010 as well as other properties required to render the objects discoverable or recognizable within FIM.
Finally, administrators determine the data they would like to use as a basis for defining dynamic groups. Although Fabrikam does not deploy dynamic groups initially, it is helpful to choose the user object attributes that would be consumed in dynamic groups.
For more information about how synchronization works in FIM, see Understanding Data Synchronization with External Systems.
Extending the FIM Service schema
Conceptually, Fabrikam needs to do two things:
Ensure that resources to be managed in FIM such as DGs have all their properties synced into FIM so that they can be managed in FIM.
Ensure that resources that are managed in, or resources that could be members of the groups managed in, must have properties synced to FIM.
This enables those resources to be discovered and differentiated by end users. For example, an administrator might need to ask, “Is this the right ‘Brian Williams’ to add to a group?”. Fabrikam needs to ensure that the FIM Service has all the information about the objects that users need to manage.
FIM 2010 provides an extensible schema with a predefined set of resource types and associated attributes. FIM 2010 makes it easy to adjust the schema—usually with only a few lines of XML.
The basic elements of the FIM schema are resource types, attributes, and bindings. Attributes are bound to a resource type to hold values that define an instance of that resource type. For example, a user resource type has multiple attributes bound to it such as DisplayName, Address, Manager, and others.
The default schema meets most but not all of Fabrikam’s needs, and so the administrators need to extend the schema with additional properties. For example, Fabrikam uses Exchange Server functionality to specify whether external senders can send e-mail messages to a Fabrikam DG. In this case, the administrators create a new attribute type in FIM 2010, a Boolean attribute that specifies whether the group allows mail from external senders. Then, they bind that data to a group object type. For information about the structure and components of the FIM schema and for instructions about how to extend it, see Introduction to Custom Resource and Attribute Management.
Implementing synchronization rules and initializing synchronization
After Fabrikam determines what needs to be synced from AD DS to the FIM Service and configures the schema in the FIM Service to store the needed data, administrators need to implement sync configuration to bring in the data. This requires that the administrators perform two overall tasks:
Initialize the environment by bringing users and groups from AD DS into the Active Directory connector space and into the FIM metaverse.
Export these objects from the FIM management agent into the FIM Service.
For information about how to implement synchronization rules, see Introduction to Inbound Synchronization and Introduction to Outbound Synchronization.
Determining objects to which FIM must be authoritative
In this phase, Fabrikam chooses the groups owned by the pilot users for an initial rollout. It is important to think about a structural approach that makes sense for the organization. This could be everyone in a particular department such as Sales or HR. Or, it could be everyone in a specific division within the company. Fabrikam chooses to pilot all the users in the HR department. To do this, they verify which groups are owned by the HR users and then make FIM authoritative for those groups. At Fabrikam, the owner of the group is stored in the ManagedBy property in AD DS. Consequently, when administrators make FIM authoritative for these groups, they need to ensure that the ManagedBy property is brought into both the DisplayedOwner property and the Owner property. Thereafter, any change to group owners should be made only in FIM, not AD DS.
For more information, see Introduction to User and Group Management.
Determining initial users and implementing a set to define those users
Fabrikam has designated all users in HR as pilot users. To implement a set to define these users, Fabrikam completes the following steps:
Determine the pilot users
Implement a set with pilot users as members
Ensure that set is used in MPRs which grant permission to use selfhost
Determine the groups owned by the pilot users
Set the value of “owner” & “displayed owner” in the FIM Service for the groups that are owned by pilot users
Ensure there is a set that includes as members only those groups for which FIM should be authoritative
Ensure the sync rule for provisioning groups from FIM to AD DS, uses that set
For more information about implementing sets, see Designing Business Policy Rules.
Configuring FIM to Provision Groups to AD DS
Since Fabrikam wants FIM to be authoritative for certain groups in AD DS, it needs to configure the FIM Service to sync data to AD DS. It does this in three steps:
Determine which attributes to flow from FIM to AD DS
Implement a sync rule to flow those attributes from FIM to AD DS
Implement a set, workflow, and an MPR to sync groups to AD DS
Determining the object attributes that flow from FIM to AD DS
Fabrikam determines the attributes it needs to flow from FIM to AD DS. The basic attributes that AD DS and Exchange Server need for DGs are:
Display name
Type of group
Alias
CN for the group
There can be additional attributes that users can manage in FIM. In Fabrikam’s case, this includes the Requires sender authentication attribute.
In the FIM Portal, Fabrikam then implements a sync rule to flow these attributes from FIM to AD DS and configures a workflow to assign a group to this sync rule. Then, it creates a set that is defined as all groups for which FIM is authoritative and creates a transition MPR to execute the workflow when a group transitions into this set.
For instructions about provisioning groups to AD DS, see How Do I Provision Groups to Active Directory Domain Services (https://go.microsoft.com/fwlink/?LinkID=188280).
Configuring policies to allow completion of basic scenarios
Fabrikam needs to ensure that end users have sufficient permission to manage their groups in FIM, while also ensuring the appropriate security for end users.
To do this, Fabrikam modifies the default MPRs for distribution list management in two steps:
Grants permission to end users to complete tasks related to DG management by setting the Disabled property of these MPRs to false
Modifies the attributes property of these MPRs so that group owners can set the values of attributes for which Fabrikam has extended the schema for groups
For more information about using policies in FIM, see Designing Business Policy Rules.
Configuring RCDCs to expose all needed attributes
Fabrikam wants end users to manage the properties for which it has extended the group schema. For example, administrators can configure RCDCs to provision the following:
Authenticated senders
Welcome message
FIM managed
To do this, Fabrikam modifies the three RCDCs for the groups Create, Edit, and View. Specifically, for each of these RCDCs, Fabrikam modifies the XML so that each of the new attributes is bound to a control. The user can then read or set the value of the property, depending on their permissions.
For more information about using RCDCs to customize the user interface, see Resource Control Display Configuration XML Reference.
Testing
Fabrikam needs to verify that group functionality and security are appropriate and complete before deploying in a production environment. Typically, this is achieved by first deploying FIM 2010 in a staging environment and creating a test account that falls into the set of targeted users. Administrators develop a test plan and compare actual results against expected results. Then, they can verify that the production environment is ready to go live for the HR group. In addition, administrators test the export to AD DS by running FIM Import, FIM Synchronization, and Active Directory Export Preview.
For more information about migrating from a test environment, see Configuration Migration Deployment Guide.
Production
After completing testing in the staging environment, Fabrikam decides that it is ready to bring its DG management solution into production.
To achieve this, Fabrikam completes the following processes:
Exports the sync configuration from the FIM Synchronization Service in the preproduction environment
Exports the policy configuration from the FIM Service in the preproduction environment
Installs FIM on the servers in the production environment
Imports the sync configuration into the FIM Synchronization Service in the production environment
Imports the policy configuration into the FIM Service in the production environment
Initializes the production environment by running the AD DS to FIM sync job, and verifies correct provisioning to FIM
Verifies correct end-user functionality in the FIM Service
Runs the FIM to AD DS sync job and verifies correct provisioning to AD DS
Communicates to users that they can begin using the service
Initiates a script to regularly run the Sync Active Directory to FIM job and the Sync FIM to Active Directory job
Expansion
After Fabrikam has successfully deployed FIM self-service DG management functionality to the pilot users in the HR division, Fabrikam decides that it is ready to expand deployment to the rest of the company, which it decides to do in stages.
For each division that it teaches to use FIM, Fabrikam:
Determines which users to add to the pilot and grants permission to those users to use FIM by adding them to the set of Fabrikam DG Mgmt Users
Determines which groups should now have FIM be authoritative and adds those groups to the set of Fabrikam FIM-managed DGs
Communicates to the new users that their groups are now managed by FIM and includes links to instructions about using FIM and Fabrikam’s policies for doing so
Conclusion
By deploying FIM self-service DG management to the company, Fabrikam met its business objectives. By empowering users to create and manage their own DGs, Fabrikam achieved:
Lower cost. Fabrikam significantly reduced the number of helpdesk calls from users for DG-related requests. Because of the reduced volume of helpdesk calls, Fabrikam reduced the ongoing expense of its outsourced helpdesk service.
Higher end user productivity. Fabrikam end users improved their productivity because they were able to easily complete their DG-management tasks by using a familiar user interface. There was no need to interrupt their workflow with calls to the helpdesk. And, their changes were completed faster because they did not need to wait for helpdesk to complete the request.