Download.microsoft.com



[pic]

Planning and Deploying SharePoint Server 2010 User Profiles for My Site Web Sites

This document is provided “as-is” and expands on and provides screenshots for the information provided in the following Microsoft TechNet articles:

• Plan user profiles

• My Site Web sites overview

• Plan for My Site Web sites

• Plan for profile synchronization

• Configure profile synchronization

Information and views expressed in this document, including URL and other Internet Web site references, may change without notice. You bear the risk of using it.

Some examples depicted herein are provided for illustration only and are fictitious.  No real association or connection is intended or should be inferred.

This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes.

© 2010 Microsoft Corporation. All rights reserved.

Planning and Deploying SharePoint Server 2010 User Profiles for My Site Web Sites

Scott Jamison & Donal Conlon

Jornata LLC

April 2010

Applies to: Microsoft® SharePoint® Server 2010

Summary: This whitepaper provides prescriptive guidance about profile synchronization and My Site planning and administrative tasks for SharePoint Server 2010. The whitepaper uses a combination of real-world scenarios, step-by-step instruction, and screen shots to guide the reader. (54 printed pages)

Contents

About this whitepaper 6

User Profiles 6

My Site Web Sites 7

Practical Guidance 10

SharePoint Server 2010 Profile Synchronization 10

Overview 10

How User Profile Synchronization Works 10

Planning 10

The importance of planning 11

Clarify Your Business Goals 11

Planning My Site Web Sites 11

Planning Permissions 11

Planning Container Selection 13

Profile Property Mappings 13

Selecting Properties 14

User Profile Property Template 14

Planning the Query Filter 17

Implementation 17

Core Configuration of the User Profile Service 17

Assumptions 17

Prerequisites 17

Configure the User Profile Service Application 18

Start the Synchronization Service 19

Working with User Profile Properties 20

Synchronization Connections 22

Get ready for Synchronization 22

Sync with AD DS 23

Sync with LDAP 28

Importing Profiles 30

Applying Filters to a Connection 32

Exporting Attributes to AD DS 33

Configure a Property for Export 33

Using Properties from Business Connectivity Services 34

Scenario 1: Single Value Property 35

Scenario 2: Multi-value Property 40

Multiple Domains and Forests 46

Scenario 1: Adding a Second Domain to the AD DS Forest 46

Scenario 2: Resource/Logon Forests 47

Operational Considerations 51

Upgrade versus Clean Installation 51

Scheduling Recommendations 52

Managing people who leave the company 53

Performance 53

Why Not to Use a SAN 53

Import Times are Non-Linear 53

High Availability 53

Backups 53

Moving the Service 53

Conclusion 54

Additional Resources 54

About the Authors 54

About this whitepaper

When designing a solution for business collaboration and social computing, it is important to think about a ‘social identity’ that represents each user in the organization. This identity, which lives in SharePoint Server, is typically an aggregate of data from directory sources such as Active Directory® Domain Services (AD DS) and other business systems.

Providing a social identity enables the users of your solution to:

• Gather insight into other users based on their social network, such as informing them about what the people they know are doing

• Provide social feedback in the form of ratings, comments, and tags

• Find an ‘expert’ – a mechanism that provides a way for users to locate a person within the organization based on profile attributes

• Provide an accurate organization chart so that users know the reporting structure

• Display items such as human resources news, based on the user’s organization and business role within the company

• Show a picture of your users in Outlook via the social connector

If you plan to use social computing features, such as My Site Web sites or People Search in Microsoft SharePoint Server 2010, you will likely want to integrate profile information that you have stored in a directory service such as Active Directory Domain Services (AD DS) or a business system such as SAP or Siebel, with SharePoint Server 2010. By using Profile Synchronization in SharePoint Server 2010, you can do exactly that. Below are two cornerstone features in SharePoint Server 2010’s ‘social identity’ capability set. This section contains overview information about these features.

User Profiles

User profiles allow you to search for and connect with people within your organization, based on information published about them. SharePoint Server 2010 provides a search scope for searching people.

In SharePoint Server 2010, you can import user profile information from Active Directory Domain Services (AD DS), LDAP servers (Sun, Novell, IBM), or from applications registered in Microsoft Business Connectivity Services, or you can enter it manually. You can customize the default user profile by adding properties according to the needs of your organization, mapping the properties to AD DS or other directory sources. SharePoint Server 2010 also provides write-back capabilities to update key data items back to AD DS such as a user’s profile picture, mobile phone number, and so on.

My Site Web Sites

My Site Web sites provide the capability to display user profile information about users within your organization, enabling others to view status updates, contact information, and other useful data. Users can publish a personal blog, subscribe to a feed of colleague activity, and interact with other users via their note board.

[pic]

A user profile visible to everyone

In order to realize the full potential of My Site Web sites, user information from the profile database should be populated. All information about a user is stored in the user profile database of SharePoint Server 2010.

My Site not only allows the display of user profile information but also gives the ability to edit properties and various levels of control as to who sees the data. Users can modify their profiles and determine values and audiences for certain properties. For example, a user can decide to enter his or her home phone number but only make it visible to colleagues.

[pic]

What the user can edit and the ability to select the level of visibility is controlled by the administrators through the user profile service.

Some properties will not be editable by users, and some properties will not allow users to select the audience. Below is an image of a user profile in edit mode.

[pic]

Editing the user profile

The Manager field allows SharePoint to display an organizational hierarchy based on a reporting structure. The profile page shows a basic organizational chart, allowing you to quickly see who the user reports to, his or her direct reports, and also peers. In addition to this, a richer organizational chart is provided using Silverlight® allowing you to click-through to follow a report structure.

[pic]

The Silverlight organization chart

With all this information in My Site profiles, we can also enjoy a rich search experience. People Search in SharePoint Server 2010 takes advantage of the user profile properties to display a “business card” format for the results.

[pic]

People Search in SharePoint Server 2010

With the amount of functionality that My Site Web sites provides, user profile synchronization is critical to the successful deployment of profiles and a personalized, social identity for each user.

Practical Guidance

This whitepaper is prescriptive, in that it instructs an IT administrator with exact steps to take for a number of scenarios. Specifically, the scenarios provided for in this whitepaper include:

• Single Forest, Single Domain

• Single Forest, Multiple Domain

• Multiple Forests (Logon Forest & Resource Forest)

• Synchronizing with Business Connectivity Services

Throughout the whitepaper, we will use a fictitious company called Contoso to illustrate the planning and implementation stages, outlining the exact steps necessary to achieve a specific outcome.

SharePoint Server 2010 Profile Synchronization

Overview

The user profile synchronization service in SharePoint Server 2010 is designed to synchronize attributes from a variety of directory sources into the user profile database of SharePoint Server 2010.

Profile synchronization can occur when profile information has changed in the SharePoint Server 2010 profile store or when profile information has changed in the source directory service or business system. After you configure Profile Synchronization, changes to either store are detected. Import or export occurs depending on the import/export settings for a particular user profile property.

How User Profile Synchronization Works

In Microsoft® Office SharePoint® Server 2007, profile synchronization was based on the SharePoint search engine. In SharePoint 2010, the underpinnings for profile synchronization are now based on Microsoft Forefront® Identity Manager. For a detailed conceptual understanding of profile sync architecture, see How user profile synchronization works in SharePoint 2010.

Planning

Before you consider making any configuration changes regarding user profiles in SharePoint Server, you should first plan well. Proper planning is very important when it comes to user profiles, since there are a number of items you must consider.

When planning for profile synchronization in SharePoint Server 2010, you first have to determine the directory services and business systems with which you want to synchronize profile information.

The importance of planning

Planning requires a number of key steps, including:

• Clarifying your business goals

• Planning My Site Web sites

• Planning permissions

• Planning container selection

• Planning profile properties

• Planning Filters

Clarify Your Business Goals

Let’s take the case of our example company. Contoso is interested in providing a user-centric SharePoint experience to its employees including People Search, social feedback, and other features. This will require a fully populated profile database, which will synchronize with external sources: AD DS and SQL Server (through Business Connectivity Services). In addition, Contoso has two domains, so we’ll walk through the configuration of a multi-domain scenario.

Planning My Site Web Sites

If user profiles are the cake, then My Site Web sites are the icing on that cake. My Site Web sites “bring to life” the user profiles in the form of a social identity landing area for each user, enabling profile properties to be searched, viewed, and acted upon.

Planning Permissions

After you have identified the directory services and business systems with which you want to synchronize profiles, you must make sure that you have the required permissions on both SharePoint Server 2010 and on the directory service or business system to which you will connect. For example, if you plan to do incremental synchronization, you must know the correct permissions that are needed for the directory service to determine the profile information that has changed.

Note: You should always follow the rules of Least Privileges deployment. This means that you should not give more permissions than is absolutely necessary for the goal you intend to meet. For example, you should not ever make your farm administrator account or your user profile service account a domain administrator. This is a far too common practice when having to carefully set granular permissions for a specific scenario. This whitepaper provides specific guidance regarding the precise permissions you will need for configuring user profile synchronization.

The following table lists the required permissions:

|Service |Permissions |

|Active Directory Domain|In order to read (import) data, the user profile synchronization service account needs: |

|Services (AD DS) |Replicate Directory Changes to connect to the AD DS domains from which you want to import data |

| |Replicate Directory Changes on the cn=configuration container. This is only necessary if the NetBIOS name is different |

| |from the domain name. In this situation, the configuration container provides the authoritative answer to the right |

| |NetBIOS name. In addition you must enable NetBIOS domain names on the corresponding User Profile service application. |

| |This can be achieved by running the following script using the SharePoint Administration Shell: |

| |Get-SPServiceApplication |

| |$UPA = Get-SPServiceApplication –Id |

| |$BIOSDomainNamesEnabled=1 |

| |$UPA.Update() |

| |In order to write (export) properties from SharePoint Server to AD DS, the user profile synchronization service account |

| |needs: |

| |read/write permissions on the container or if available, on the property Writing properties back to AD DS will be a |

| |common scenario. |

|SunOne (LDAP) |Connect - Any enabled user |

| |Full sync - Anonymous access to RootDSE for Read, Write, Compare, and Search rights. |

| |Incremental sync - Same as full sync plus Read, Compare, and Search permissions for the cn=changelog object. |

|Novell eDirectory |Connect - Any enabled user |

|(LDAP) |Full sync - Browse rights in the “Entry rights” property for the specified tree. Read, Write and Compare rights in the |

| |“All attributes rights” for the specified tree. |

| |Incremental sync - Same as full sync |

|Business Data |No permissions required |

|Connectivity service | |

|IBM Tivoli (LDAP) |Full sync and incremental sync – Must be a member of an administrative group. |

We recommend that you determine the required permissions for the environment before setting up Profile Synchronization.

It is important to note that SharePoint Server 2007 did not require specific permissions in order to read properties from Active Directory Domain Services. In a SharePoint Server 2010 scenario, this may cause confusion (or worse yet outright objections) from the AD DS team, because now specific permissions must be configured for the SharePoint service account. We suggest planning this permission requirement as far in advance as possible. For AD DS administrators, it is important to realize that the specific permission (replicate directory changes) will not adversely affect your AD DS domain environment. The permissions simply enable SharePoint Server to work more efficiently by detecting granular changes and only replicating those, rather than scanning the entire list of user objects. In turn, this will actually greatly reduce the amount of traffic generated by SharePoint Server against the AD DS server.

An additional consideration is the ability to write back to AD DS (for things like profile pictures). This will require an additional set of quality assurances to ensure that AD DS is being correctly updated. We recommend testing this in a test domain prior configuring this in production.

Authenticated users who have Replicate Directory Changes permissions will be granted read-access to AD DS objects. Additional permissions can be granted by using access control lists (ACLs) in AD DS. SharePoint Server 2010 will not write profile data back to AD DS unless Write permission is explicitly set on the container for the account that has Replicate Directory Changes permissions and a SharePoint property is mapped to export to the directory source. There are no mappings included in SharePoint Server to export properties out of SharePoint Server.

Planning Container Selection

Before you can do an initial import of profile information from a directory service or business system to SharePoint Server, you must determine the directory service or business system containers that you want to import and synchronize. For example, you must determine which directory service containers have the user profiles and/or group profiles that you want to synchronize. This information is used when you first create the Profile Synchronization connection.

In our Contoso example, the users that should be synchronized are contained in an OU named “All” within an OU named “Contoso People”, while the groups are stored in an OU named “Contoso Groups”.

Profile Property Mappings

After you have determined the containers that you want to import and synchronize with SharePoint Server, you must list which profile properties in the directory service or business system map to the profile properties in SharePoint Server. You must also consider any properties that must be mapped across multiple directory services or business systems as these are not automatically mapped in SharePoint Server 2010.

When mapping profile properties, you must use consistent data types wherever possible. For example, if a user profile property in the directory service or business system uses an integer data type, map the external property to a user profile property in SharePoint Server 2010 that uses the integer data type. Do not map the external property to a user profile property that uses a different data type. That is, do not try to map an integer property to a string property. If you don’t see a property listed when mapping, it’s very likely because of property mismatch. If you used a mismatched property type map in SharePoint Server 2007, you’d need to delete that property in SharePoint Server, recreate it with the correct type, and then map it.

Selecting Properties

Before you configure any properties, you should create a list of all user profile properties that you want to capture. We recommend that you have a business analyst gather a comprehensive list of properties up front. A design session works well for this purpose; you can determine which properties are important for your business collaboration and social computing scenarios. This session should include questions like:

• What core contact information should we include for users? Where is the definitive location for each of those properties?

• Should we include office location, business unit?

• Do we let users update their own information? If so, which properties do we show?

• Do we need to write back to the source location? If so, how does that impact our security plan?

This planning session is important, since it will tie into your governance policies and your policy for Personally Identifiable Information (PII). Any new property that is added to the user profile property list will require a full synchronization with the corresponding directory source. Ideally, changes to the user profile property list will be infrequent and strictly controlled through change management.

User Profile Property Template

As part of our design process, we recommend using a template that enables a business analyst to collect and capture the list of user profile properties for an organization, specifying such items as source location, read/write-back status, visibility, and user editability. This template makes it easy for the business to see the properties at a glance and for the SharePoint administrator to configure the appropriate settings within SharePoint Server.

In our example, Contoso successfully used the template to map out properties for its organization. In their scenario, most properties are stored in AD DS, with HR-specific information stored in an HR database (accessed via Business Connectivity Services) and Finance-specific information in an LDAP store. Additionally, profile pictures are stored in SharePoint Server 2010 and then synchronized back to AD DS by using Export. This configuration is required by the Microsoft Outlook Social Connector to ensure that photos show up correctly.

The following table is an example of the properties that Contoso came up with.

Note: This subset is a representative list and is not necessarily comprehensive.

|Property Name |Source Location |

| |SPS-DistinguishedName |

|objectSid |SID |

|manager |Manager |

|displayName |PreferredName |

|givenName |FirstName |

|Sn |LastName |

|PhoneticDisplayName |PhoneticDisplayName |

|PhoneticFirstName |PhoneticFirstName |

|PhoneticLastName |PhoneticLastName |

|telephoneNumber |WorkPhone |

|mail |WorkEmail |

|physicalDeliveryOfficeName |Office |

|title |Title |

|department |Department |

|sAMAccontName |UserName |

|wWWHomePage |PublicSiteRedirect |

|SIP Address |proxyAddresses |

Groups:

|AD DS attribute |User Profile store property |

| |SourceReference |

|objectSid |SID |

|displayName |PreferredName |

|description |Description |

|url |Url |

|member |Member |

|groupType |GroupType |

|mail |MailNickName |

Planning the Query Filter

There may be instances when you want to exclude some profile information from being synchronized. In SharePoint Server 2010, you can set filters on a Profile Synchronization connection to prevent certain user or group properties from being synchronized. Since you will do planning well in advance of setting up Profile Synchronization, you’ll have a list of the profile properties that you want to exclude. Remember that this is an exclusion filter, and that setting inclusion filters is not supported in SharePoint Server 2010.

Implementation

Once you have completed and verified your planning process, you can move onto the implementation stage. Your planning documents should be well-managed, change-controlled, and approved by your governance committee before implementing changes within SharePoint Server itself.

Core Configuration of the User Profile Service

The first step is to configure the user profile service and provision the user profile synchronization service.

Assumptions

It is assumed that a SharePoint 2010 farm already exists and has been configured. Profile Synchronization will not work on a stand-alone SharePoint installation.

The following accounts are in effect in the domain:

• SharePoint Administration Account – Used for installation and administration

• SharePoint Farm Account – Used during configuration and for database communication

Prerequisites

Before we configure the user profile synchronization service we need to make sure some prerequisites are installed.

On the server that's running SharePoint Server and where you are configuring the Synchronization Service (the Central Administration server):

Patches

• SQL Server 2008 should have Service Pack 1 and Cumulative Update 2 applied.

Permissions

• The farm account should be a member of the local administrators group on the server that's running SharePoint Server.

• The farm account can log on locally to the server that's running SharePoint Server.

• The farm account should be an administrator for the User Profile Service application.

Service Applications

• A Metadata service application should be in-place and configured

• A User Profile Service application is required to run the synchronization service.

The following steps will walk through configuring all of the above prerequisites before proceeding to setting up the synchronization service.

Configure the User Profile Service Application

The User Profile Service is a shared service in Microsoft SharePoint Server 2010 that enables the creation and management of user profiles that can be accessed from multiple sites and farms. When you enable the Synchronization service, you associate it with a user profile service application, so we need to create this first.

From SharePoint Central Administration, browse to the Manage Service Applications page. Create a new User Profile Service Application from the New button on the ribbon. The next page asks you to provide information regarding the service application including database names for profiles, synchronization, and social tagging, My Site properties, and application pool details.

[pic]

After providing all the details and clicking Create, the three databases will be created in SQL Server, and the service application will be created and started. Confirm that the service application is started before moving on to the next step.

[pic]

Only one instance of Forefront Identity Manager (FIM) Synchronization service can run on a server. If you have multiple User Profile Service Applications, then you have to synchronize them by using FIM on multiple servers.

Start the Synchronization Service

At this point we have assigned the appropriate permissions, and created the user profile service application. We are ready to start the User Profile Synchronization Service on the server that is running SharePoint Server. From Central Administration, browse to the Manage services on server page. On this page, you will already see two user profile related services, one for the profile service, and another for the synchronization service. The User Profile Service will have been started when the service application was created earlier. The User Profile Synchronization Service will have a status of Stopped.

IMPORTANT: After creating the User Profile Service, you must do an IISRESET before starting the User Profile Synchronization Service.

To start the synchronization service, click Start in the Action column. This will display a page requesting details relating to the service, including which Service Application to associate with the service, and the password for the service account.

[pic]

When you click OK to start the synchronization service, a SharePoint timer job will execute to complete the service configuration. Upon completion, the service status will change from Starting to Running. You will also see that two Windows services, Forefront Identity Manager Service and Forefront Identity Manager Synchronization Service, are running.

[pic]

New folders, ILMMA and MOSS-, will also be created in the SharePoint install folder (C:\Program Files\Microsoft Office Servers\14.0\Synchronization Service\MaData).

[pic]

If these folders are not created or if the FIM services are not started, do not manually create or start them. The service may take up to ten minutes to start. If the service fails to start, review all the prerequisites and start again.

Working with User Profile Properties

The user profile synchronization process is based on importing specific values from the directory source. SharePoint Server provides a number of preconfigured properties that map directly to standard properties in external sources such as AD DS. These predefined properties can be viewed from the Manage User Properties page.

[pic]

This page lists all available property mappings. It will also list any custom properties that you create.

While editing one of these properties, we will notice several sections of interest, namely Policy Settings, Edit Settings, Display Settings, and Property Mapping for Synchronization (in addition to other options).

Each of these sections gives us great control and flexibility in how the properties are synchronized, and then used within SharePoint Server.

Administrators can apply policies with the following settings:

|Policy Settings |Options |Information |

|Policy Setting |Required |Determines if this is a required attribute, or if|

| |Optional |it’s disabled. |

| |Disabled | |

|Privacy Setting |Only My |This setting gives you great control over who |

| |My Manager |sees this value. |

| |My Team | |

| |My Colleagues | |

| |Everyone | |

|User can override |Yes/No |Specify if use can change from the default |

| | |settings |

The Edit and Display Settings give you control where this value gets display in the user profile. Both of these sections allow you to modify the following:

✓ Allow users to edit values for this property

✓ Show in profile properties section of the user’s profile page

✓ Show in the Edit Details page

✓ Show updates to the properties in newsfeed

Below is an image of the options when creating a property.

[pic]

You will see in the following sections how we use these properties to apply filters, map to custom attributes, and define values for export.

Synchronization Connections

Once we have our synchronization service successfully started, we can build our connections to our profile sources, such as AD DS. For the first scenario, let’s assume Contoso has a simple environment consisting of a single forest and a single domain. We’ll expand on this with additional scenarios in the sections that follow.

From the Service Application page, select the profile service application in the list, and click Manage on the ribbon. The image below shows the management page for the User Profile Service. Initially, this will show the number of user profiles as zero. After we successfully run an import, this number will change.

[pic]

Browse to the Configure Synchronization Connections page where we will create a new connection for AD DS. The connection page, allows you to define the source type from one of the following:

• Active Directory Domain Services

• Active Directory Logon

• Active Directory Resource

• Business Data Connectivity

• IBM Tivoli Directory Server

• Novell eDirectory

• Sun Java System Directory Server

Get ready for Synchronization

Before we create our connections for synchronization, we need to consider our settings before running any sync. The Configure Synchronizations Settings page allows us to control what entities get synchronized, as well as disabling Business Connectivity Service connections. We can also select to use an external Identity Manager such as Microsoft Identity Lifecycle Manager 2007.

[pic]

Let’s consider the first two of these options.

Synchronization Entities – If you are importing a large number of profiles from an external source, you may want to consider importing a few users to test the process. Once you are happy users are successfully imported, you can switch to include groups and then run an incremental synchronization.

Synchronize BCS Connections – If you decided to do all your connections at once before synchronizing, you may have reason for excluding Business Connectivity Service data (the source may not be ready, date needs to be verified, and so on). Clearing this option allows the AD/LDAP connections to sync, while ignoring the Business Connectivity Service connections.

Other topics for consideration are ensuring the correct permissions are set on the connection source, port numbers, domain controllers to sync with (AD DS), and so on. All of these should be considered at the planning stage.

Sync with AD DS

Before we connect to AD DS for profile synchronization, we need to prepare AD DS to allow synchronization to occur. For successful import (and export) we need to ensure AD DS gives the appropriate permissions to the account we use for synchronization.

In accordance with our least-privileges security approach, we are using a dedicated account named service.ad-sync for synchronization with AD DS. This is a separate account under which the service runs. It is a common misconception that this account needs to be the farm account or the User Profile Service account which is not the case.

We are going to import data from and export data to AD DS, so we need to configure permissions accordingly.

Configure AD DS Read Permissions

Add the farm account to the local administrators group. Right-click Computer in the start menu and select Manage. In the navigation pane, expand Configuration, and select Local Users and Groups. Open Groups and open the Administrators group. Click Add… to add the farm account to the local Administrators group.

The Administration account is also added to the administrators group to allow the user to remote into the box to carry out the installation. This can be removed post-installation to respect a least-privilege configuration.

[pic]

After the administration account (in this case, service.sp-admin) has been added to the local administrators group, they will be able to logon to the server locally.

The farm account also requires permissions in AD DS to replicate directory Changes. To set this up, follow these steps.

1. Logon to the domain controller.

2. From the start menu, open Active Directory Users and Computers

3. Right-click the domain and select Delegate Control.

[pic]

4. Click Next, and select the service account that we are delegating control to.

[pic]

5. On the Tasks to Delegate window, select Create a custom task to delegate and click Next.

[pic]

6. Leave the default selection for delegation scope.

[pic]

7. For Permissions, select Replicating Directory Changes.

[pic]

8. Click Next and Finish to complete the wizard.

Configure AD DS Write Permissions

In addition to the read permissions listed above, there may be a scenario where you want to write back to AD DS (for example, for a thumbnail of the user’s photo). At the container level (OU), you will need to give the account permissions of Read and Write (by default it applies onto this object and all child objects). To apply this permission use the AD tool ADSI Edit to navigate to the container to apply the permissions to.

[pic]

To accommodate Least Privileged rules, you should use the advanced setting for write permissions, which enables you to select properties at a granular level. For example, if only exporting the user photo to AD DS, then you should select the specific permissions for thumbnailPhoto attribute.

Create a connection to AD DS

From the connection page, select Active Directory as the connection type. Provide the service account that you plan to use to sync with AD DS in the connection settings section. For our connection we are choosing to auto-discover the domain controller as we only have one in our domain. However if you want to sync with a specific domain controller, you should specify the server name.

The default port for connections to AD DS (and LDAP) is 389 which is what we are using. You should check with your AD DS administrator to confirm this.

[pic]

Scroll to the Containers section and click Populate Containers to return the AD DS containers. From the container tree, you can choose the objects that you want to synchronize with the User Profile store. By doing the proper planning beforehand, we know exactly which containers to select.

[pic]

Sync with LDAP

Some organizations might use an LDAP server as the directory service, in place of AD DS. SharePoint Server 2010 supports the following LDAP directories:

• Novell eDirectory version 8.7.3 (LDAP): Only Full Sync for users is supported in SharePoint Server 2010.

• SunOne version 5.2 (LDAP): Both full and incremental are supported. You must set up a change log to use Incremental Sync.

• IBM Tivoli 6.2 (LDAP): Both full and incremental are supported.

AD LDS is supported through Business Connectivity Services, in concert with an AD DS or LDAP server that is used as the directory service for users.

Configure Membership Providers

In order to create an LDAP connection, you will need to update your Central Admin web.config with the LDAP Membership Provider so that it will show up in the Authentication Provider Instance drop-down box. The image below shows our web.config modified to include connection for an LDAP role and membership provider.

[pic]

With our membership connection properly configured, we will be able to select it as the authentication provider instance when creating an LDAP connection.

Create a connection to LDAP

Similar to creating the AD DS connection, we select an LDAP option for the connection type. After you select the type, your options will change and allow you to specify the authentication provider, the account to use for connection, and also the user attribute to use to match user name. You will notice the default port is the same as the AD DS connection type.

[pic]

After your connection is created (and synchronized), LDAP data will be merged with the user profile based on the uid attribute for the username.

An attribute other than uid can be used if it contains the appropriate value, for example if you changed the uid attribute name to something else. If the attribute specified does not exist, however, the uid attribute will be used.

Importing Profiles

After the connections to profile sources are defined, we can start synchronizing. From the Manage Profile Service Page, select Start Profile Synchronization. Initially we will choose to do a Full Synchronization, but any subsequent manual syncs can be incremental.

[pic]

The synchronization process will continue to populate the user profile store until it has processed all connections. You can check the progress of the import by opening the Timer Job Status page in Central Admin (in the Monitoring section), where you will see the User Profile Service Application job.

[pic]

You will notice the number of profiles increase as they are imported.

Note. You can check the progress of the synchronization by clicking the Synchronizing link in the Profile Synchronization settings section.

[pic]

This will display a log that indicates the various tasks that the synchronization service has completed. A sample of the log is provided in the following image.

For a detailed understanding of how User Profile Synchronization actually works under the hood, see How user profile synchronization works in SharePoint 2010.

[pic]

Applying Filters to a Connection

AD DS (or another source) can contain many objects as well as users that you may not want in SharePoint Server. For example, it might contain external partner information or customer information. When creating your synchronization connection, you can be selective about the profiles that you want to import. If your directory made good use of containers, it may be as easy as not selecting the containers that you do not what to import. Even at that, there are many valid reasons to want to exclude users in a container that do not meet certain requirements.

Profile filters allow you to add exclusions to the connection, thus allowing you to use rules to restrict the profiles that get imported based on attribute values.

After your connection is created, you can apply filters to it to select only profiles based on certain attribute values.

From the synchronization connections page, select the connection that you want to apply filters to. Select Edit Connection Filters from the menu to start adding filters.

[pic]

The filters page allows to add several exclusion filters by using AND or OR logic and allows you to apply filters to users or groups.

For our example, we are going to apply the filter which prevents disabled accounts from being imported.

Below is an image of the filter after it’s added.

[pic]

To filter out disabled accounts, we need to exclude profiles where the attribute userAccountControl (Bit on equals) 2.

Filters are applied at the connection level, so you can apply multiple filters to any of your connections. Bear in mind that filters are exclusion filters, meaning that you need to select the containers to import filters first, and then use filters to reduce that set.

Exporting Attributes to AD DS

While there is a lot of information that Contoso wants to ensure is consistent and accurate (for example, email address, employee manager, department, title, and so on), there is often the requirement for the user to manage some personal data themselves, for example, cell phone number, user profile photograph, and so on. The User Profile Service accommodates this by allowing you to export certain attributes back to the connection source.

A common attribute to export from the user profile is the user’s picture. This can then be used by the Outlook Social Connector to display the user picture in Outlook alongside e-mail messages, and so on.

Configure a Property for Export

From the Manage User Properties page, locate the Picture property, and edit. We are going to add another mapping to Export the property to AD DS. Select thumbnailPhoto as the attribute to export, and set the direction to Export.

[pic]

Click Add to assign the mapping to the property. The next time the synchronization runs, the service will export the user thumbnail image to AD DS.

[pic]

The image above shows the properties for an AD DS. Here we can see the thmbnailPhoto property is populated.

Using Properties from Business Connectivity Services

There are instances when the user profiles will need to be augmented by additional properties found in a third-party system (for example, a Human Resources application) or other database. The User Profile Service simplifies the mapping of such properties by providing the ability to use a connection via Business Connectivity Services.

Scenario 1: Single Value Property

In our example, Contoso HR houses Employee data in a SQL Server database that only Contoso HR can access. While this database contains properties that are sensitive such as social security number, it also contains properties that are useful to have in SharePoint User Profile store such as Date of Birth and Employee ID. To synchronize these properties, you will need to :

✓ Create an external content type

✓ Configure security for content type

✓ Create user profile synchronization connection

✓ Add/Edit properties

✓ Run synchronization job

Database Schema

The HR employee database contains a table named EmployeeData with the following columns:

[pic]

We only want to synchronize with the EmployeeID and DateOfBirth columns. The EmailAddress column is the column we will use as our key to match the user in the profile store.

External Content Type – Employee Data

From Microsoft® SharePoint® Designer 2010, select External Content Types from the navigation pane, and click New on the ribbon to create a new external content type.

[pic]

From the summary view, we define the name, before clicking Operations Design View to define our connection and operations.

We add a SQL Server connection to our database, and create the Operations that we want by right-clicking the Employee Data table and selecting from the menu. Because we only want to read the data from the HR database, we only need the Read Item operation.

[pic]

The Return Parameter Configuration page allows you to define the columns to pull from the table.

[pic]

With our external content type configured and created, we can now use this to create a synchronization connection.

Business Connectivity Services Application Permissions

Before we can use the external content type to synchronize, we need to give the application pool account that the User Profile Application Service uses permission to use it. From the Manage Service Applications page in Central Administration, select the Business Connectivity Service application, and click Manage. Here you will see the external content type we created earlier. Select the content type in the list, and click Set Object Permissions on the ribbon. Add the service account that is used, and assign it the appropriate permissions. Because we are only using this to pull data from the connection, we need Execute and Set Permissions.

[pic]

Create Synchronization Connection

On the User Profile Service management page, click Configure Synchronization Connections. From here we can create a connection to the external content type by creating a connection of type Business Data Connectivity. Select the external content type, and select WorkEmail as the identifier. The WorkEmail column will be used to match an existing profile to a row in the table, so properties pulled from the table will be applied to the correct user profile.

[pic]

Add Custom Profile Property

We need to define the properties that get populated from the Business Connectivity Services external content type. From the Manage Profile service Page, select Manage User Properties in the People section. Here you will see many existing properties. We can choose to map an existing property to the Business Connectivity Services data, or we can choose to create a new property. We’re going to first create a new property for the EmployeeID column.

[pic]

From the Manage User Profiles Page, click New Property. Enter all the values to define the property. At the bottom of the page is the mapping information. Here, we select the connection that we created to the external content type, as well as the attribute we want to map to. Once you select the attribute to map and click Add, you must also click Ok to save the changes.

[pic]

We do the same for a new Date of Birth property, and map it to the column from the Employee table. After all properties have been configured correctly, we can run a full import by selecting Start Profile Synchronization on the Manage Profile Service page.

After the import is complete, we will have properties from both AD DS and SQL Server database (via Business Connectivity Services) promoted to the same user profile.

Scenario 2: Multi-value Property

We have shown how to populate a single-value field (EmployeeID) from our Employees table in SQL Server. However there is often the requirement to pull multiple values from a table for a specific user. The example we are going to use is Schools; an employee can attend many schools in their lifetime. The user properties table already includes a field for Schools, so we are going to use this rather than creating a new custom one.

Similar to above we are going to do the following:

✓ Create an External Content Type for Schools

✓ Configure security for content type

✓ Create a new user profile synchronization connection

✓ Relate the Schools field to the Business Connectivity Services field

✓ Run an incremental synchronization

Database schema

If we look at what we have in our database, we will see another table named Employee_Schools. This table contains a record that relates users to schools. If an employee attended two schools, there will be two records for that user, one for each school attended. The first column is our employee e-mail address which is what we are using as our finder to relate the record to our user profile.

[pic]

External Content Type - EmployeeSchools

From SharePoint Designer, we will create a new external content type for EmployeeSchools.

[pic]

Switching to Operations Design View, we are going to create a new operation for the Employee_Schools table. For our single-value field in the previous scenario, we created a Read Item Operation; for our multi-value property, we will create a new Read List Operation.

[pic]

In the Filter Parameters section, we need to add a new filter so we can find all the schools for a single employee. The filter we therefore need is on the EmployeeEmail column.

[pic]

Next we need to map the EmployeeEmail column to the identifier EmployeeEmail.

[pic]

Click Finish to complete our operation, and then save the content type. Before we can sync this data, we need to make sure our service account can access the application.

Business Connectivity Services Application Permissions

Similar to our previous scenario, we need to give the application pool account that the User Profile Application Service uses permission to use it. From the Manage Service Applications page in Central Administration, select the Business Connectivity Service application, and click Manage. Here you will see the external content type we created earlier. Select the content type in the list, and click Set Object Permissions on the ribbon. Add the service account that is used, and assign it the appropriate permissions. Because we are only using this to pull data from the connection, we need Execute and Set Permissions.

[pic]

Create Synchronization Connection

With our external content type defined, we next create our synchronization connection to pull this multi-value data into our user profiles. This is slightly different to our first scenario. On the User Profile Service management page, click Configure Synchronization Connections where we will create our new connection.

If a synchronization job is already in progress, no changes can be applied until the job is complete.

After we select our new Business Data Connectivity Entity for EmployeeSchools, we will be able to select a 1:many connection type.

[pic]

After we select 1:many as the connection type, we select our filter and map it to the WorkEmail user profile property.

Map Multi-value Property

In our first scenario we created a custom profile property; for this scenario we are going to use an existing multi-value property and populate it from Business Connectivity Services.

Returning to the User Properties page, locate and edit the Schools property. You can verify all the default settings are appropriate, and then scroll to the Add New Mapping section where we will relate our Business Connectivity Services value.

[pic]

Select EmployeeSchools as the connection, and Schools as the attribute. After running a full or incremental synchronization, we should see our Schools field populated.

[pic]

You will notice that in this case, schools have also been added to the Managed Metadata service as keywords as it is an enterprise keyword field.

SharePoint Server will allow you to map a multi-value property in your source to a single value property in SharePoint Server. If you happen to do this, only the first value will be applied.

Multiple Domains and Forests

Some organizations use a multi-forest configuration for one or more reasons. There are two key types of multi-forest scenarios: a multi-forest configuration for separate user populations (similar to the multi-domain scenario), and a configuration whereby the organization uses a “lean and mean” logon forest for all authentication purposes, and then a resource forest that accumulates interesting information for each user. The resource forest is quite typical in an Exchange Server deployment which facilitates a greater security separation for the Exchange Server mailboxes.

Scenario 1: Adding a Second Domain to the AD DS Forest

Now that we have shown how to import profiles from our root AD DS domain (), what happens when we add another domain to the same forest? After adding a new domain to out forest (emea.), we can revise our AD DS connection on the Synchronization Connections page.

Similar to how we created a connection to our domain, we also create a connection to our new domain emea..

Our additional domain will now show up in the containers tree. We can now add our EMEA Employees container to the list of objects to be synchronized.

[pic]

Scenario 2: Resource/Logon Forests

For our multi-forest configuration, we will use a logon forest () and a resource forest (contoso-res.local). The logon forest is strictly for logon information, that is, user name and password. The resource forest will contain our SharePoint Server 2010 farm, as well as the additional user account data such as phone numbers, office location, and so on.

Below is a representation of our multi-forest configuration. You will notice that the same users exist in both forests, for example: “Contoso\John Smith” and “Contoso-Res\John Smith” represent one and the same person. When John Smith logs on to our SharePoint farm, he will logon using his credentials from the logon forest (), but his user profile information in SharePoint Server will be presented from his account in the resource forest (contoso-res.local).

AD DS Resource and Logon forests are not supported for claims authentication, trusted or forms based authentication.

Below is a representation of our resource/logon configuration.

[pic]

Assuming our multiple domains are in-place and syncing correctly, we will proceed to create two synchronization connections – one of type Active Directory Logon Data, and one of type Active Directory Resource.

AD DS Logon Data Connection

This connection will be to our farm. From the Synchronization Connections page in the User Profile Service area, click Create New Connection.

Select Active Directory Logon Data as the connection type. Enter the connection settings for forest name, and account that has access to AD DS.

Similar to a standard AD DS connection, the account used should have permission for Replicating Directory Changes. See the previous section on Configuring farm account permissions for more details.

[pic]

With all settings configured, click the populate containers button to display the AD DS containers available for synchronization.

[pic]

Once the appropriate containers are selected, click OK to complete the connection.

AD DS Resource Connection

The process for creating the resource connection is almost identical to creating the logon connection. The only difference is the connection type, and the forest we are pointing to.

[pic]

After both connections are complete, we can start a full synchronization from the User Profile Service management page.

When SharePoint imports data from a resource and logon forest, it uses the msDS-SourceObjectDN attribute to map the logon account to the resource account. If this property is not configured correctly, the user properties will be retrieved from the resource forest. Below is an example of a user account in the resource forest where it has the value set for the matching user account in the logon forest.

[pic]

After the profiles are imported, you should be able to confirm that the user data is pulled from the resource forest by checking the values of one of the profiles.

Below we can see a sample of data pulled from each forest.

[pic]

Operational Considerations

In addition to your initial configuration, you’ll also want to plan for the regular operational tasks that go into successful maintenance of your SharePoint user profiles.

Upgrade versus Clean Installation

Up to this point, this whitepaper approached the topic of My Site Web sites and User Profiles from a ‘greenfield’ point of view. However, many (if not most) SharePoint Server 2010 rollouts will be an upgrade from your existing SharePoint Server 2007 environment. Typically, when you move your databases to a new farm and upgrade the content, you must recreate the services infrastructure in the new farm, and configure the services appropriately for your new farm and new version.

In SharePoint Server 2010, two services are used for user profiles and taxonomy information: the User Profile service and the Managed Metadata service. During in-place upgrade, these two services are automatically enabled and configured. If you are using the database attach upgrade approach, you must enable and configure the Managed Metadata service before you upgrade the User Profile service to upgrade the taxonomy data as part of the upgrade.

As for databases, a new User Profile database replaces the Shared Services Provider (SSP) database that existed in SharePoint Server 2007. For an in-place upgrade, user profile data from SharePoint Server 2007 is automatically upgraded from the SSP database into a new user profile database.

For a database attach upgrade, user profile and taxonomy data from the SSP database is upgraded when the SSP database is attached, but the database is not copied and renamed. You must copy the taxonomy data into a Taxonomy database for use by the Managed Metadata service after upgrade is complete by using the Move-SPProfileManagedMetadataProperty Windows PowerShell cmdlet. Then you should reconnect the data to the Managed Metadata and User Profiles service applications. The User Profiles service and Managed Metadata service must be in the same proxy group to upgrade and use the data.

The name of the SSP database does not change during a database-attach upgrade. As such, you’ll see two databases: an SSP database and a Taxonomy database. You should rename the SSP database to “User Profiles” to avoid confusion.

Finally, you should run a full import/export to ensure that all user profile properties are populated.

Scheduling Recommendations

In SharePoint Server 2010, you can synchronize profiles on a recurring schedule or a nonrecurring schedule. Recurring Profile Synchronization is incremental; that is, only changed profile information will be synchronized. Nonrecurring Profile Synchronization can be configured to do either a full synchronization or an incremental synchronization.

The time that is required to synchronize profile information depends on several factors such as the number of user or group profiles being synchronized. A full synchronization can take days or even weeks to be completed. The time that is required to complete a recurring (incremental) sync depends on the number of profile changes that have to be synchronized.

You should plan to first perform a nonrecurring full synchronization of user profiles only before you deploy to the production environment. Then perform a recurring (incremental) synchronization of both users and group profiles.

After you have finished importing user and group profiles, you can schedule Profile Synchronization to occur on a regular basis. As part of planning, you must determine which kind of Profile Synchronization is best suited to the business model of the enterprise – recurring or nonrecurring. Account for the time that is required to perform the synchronization and determine the schedule at which you want it to run.

For many organizations, a full import will take a long time and is only recommended on a regular but infrequent basis. A one-time synchronization of user profile information between a directory service and Microsoft SharePoint Server 2010 is also called a nonrecurring synchronization. You can perform a nonrecurring full synchronization or a nonrecurring incremental synchronization of user profile information. Perform a nonrecurring full synchronization of user profile information, for example, when you want to import user profile information from external sources into the user profile store in SharePoint Server 2010 for the first time.

Note: The Start Full Synchronization option is very time intensive and resource intensive. We do not recommend this option unless absolutely required to reset data that is stored in user profiles or to do an initial synchronization of user profiles. If the profile schema changes for whatever reason, you must first perform a full nonrecurring synchronization before scheduling recurring profile synchronization. As such, be sure to plan well, both for your initial configuration as well as future changes to your schema.

In general, for ongoing operations, you will use a recurring incremental synchronization. We recommend that you set the recurring schedule to Daily.

Managing people who leave the company

When employees leave the company, they are typically either disabled or deleted from AD DS. If a user profile is disabled, the profile will remain in the profile database. If a user profile is deleted, the fourth user profile synchronization service run will remove the user from the user profile database. See Maintain profile synchronization for more information.

Performance

Why Not to Use a SAN

User profile synchronization is an I/O intensive process. You should ensure that you consider the general characteristics of the disk. For example, direct-attached storage (DAS) will likely perform much better than a storage area network (SAN) because many SANs have inferior input/output operations per second (IOPS). A minimum of 1,000 IOPS is recommended. DAS also reduces the likelihood of hitting SQL Server timeouts during sync stored procedure execution.

Import Times are Non-Linear

When calculating your import times, remember that performance is non-linear because the size of things, such as the groups, matters and will impact how much time your import will take.

High Availability

There are multiple factors to consider regarding availability when it comes to user profiles. The first is backing up the user profile database. The second is ensuring that you have a failover server that can run the user profile synchronization job if the primary server should fail. See Maintain profile synchronization for more information.

Backups

The user profile database should be backed up on a nightly basis. In the event of a data disaster, the database can be restored. However, you will have to re-provision the Synchronization service.

Moving the Service

If the server that the user profile synchronization service uses fails, you can use the Services on Server applet in Central Administration to start the service on another server in the farm.

Conclusion

This whitepaper provided prescriptive guidance regarding the proper planning of user profile synchronization and My Site Web sites in SharePoint Server 2010. In addition, we provided a step-by-step guide for configuring the proper settings. In short, remember to plan well. Almost every small change requires a full import, which is expensive.

Additional Resources

SharePoint Server 2010 user profile synchronization is based on Forefront Identity Manager (FIM). For further details on FIM, see Understanding Forefront Identity Manager 2010.

About the Authors

Scott Jamison is a principal at Jornata LLC, a Boston-based SharePoint consulting and training organization. Scott is a Microsoft Certified Master and author of Essential SharePoint 2010.

Donal Conlon is a principal consultant at Jornata LLC and has worked on Microsoft technologies since 1996. His current focus is on SharePoint 2010 solutions and custom development. Donal is also a contributing author to Essential SharePoint 2010.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download