Moss 2007 | User Profiles | Part 1

User Profiles – The Idea Behind
A user profile is a record in the profile database that contains property values about a person. This information can be listed, searched and displayed to other users in the organization. In SharePoint Portal Server (SPS) 2003, the user profile store was primarily designed for use in the Intranet environment. MOSS 2007 provides a user profile store that can be used for a much broader set of scenarios including Internet presence sites and extranet sites. Richer features like personal network and expertise management are provided. Content specific to a user or a group of users can also be targeted. This is one of the reasons why traditional user information stores like Active Directory are not sufficient enough for this feature.

User Profile information within MOSS are utilized by components such as My Sites, Colleague tracking (Manager, Peer and directs), Shared Context (When a user visits another user’s profile page, MOSS shows all commonalities between these two users such as – common manager, Distribution Lists and WSS Sites they are members of, Common colleagues etc, Privacy & Security (Restrict visibility on user profile properties, colleagues etc), Memberships (Shows DLs in Exchange Server and WSS 3.0 sites that the user is a member of) & People Search.

Import Process Explained

At a very high level, the user profile import utilizes the search infrastructure within MOSS to gather the user data from data stores (LDAP directories, SQL Databases, Enterprise apps like SAP and PeopleSoft etc). The import process uses a protocol handler shipped with MOSS to connect to the Profile store. Besides the protocol handler, we also use a component within Search to push data collected by the crawler into SQL server tables where data is held before stored procedures are executed on the data. The processed data ends up in the UserProfiles_Full table of SSP Database.

Active Directory is always the primary or master source for creating user profile information by default. This means that if a user is missing from the master connection, Office SharePoint Server 2007 assumes the user is no longer in the organization and removes the user from the SSP database. On the other hand sources defined in BDCs (Business Data Catalogs) are treated as supplementary data stores and only add additional properties to the existing user profiles. The Active Directory protocol handler connects to active directory using LDAP. During import, users, groups and their properties are imported.

NOTE: SPS 2003 supported importing user profile information only from Active Directory.

Steps in Profile import:

a. Configure user profile import Settings.
b. Retrieving information from source (Gatherer Phase).
c. Importing & Processing data in SQL Server Tables
d. Timer Jobs in User Profile Import

Configuring User Profile Import Settings

Before you can import user profile information, the import settings must be configured first. Only user accounts with access to the Shared Services Provider (SSP) Administration site (eg: Farm Admin) can configure the user profile import settings. This user must also have the “Manage user profiles” permissions enabled to complete this procedure.

Steps to Configure Import Settings

There are 2 places within Shared Services Administration site where configuration for import settings is configured. They are:

a. Configure Profile Import
b. View Import Connections

Configure Profile Import provides for configuring settings for importing user profiles from Active Directory or LDAP compliant Directory Service. View Import Connections provides for managing the list of connections to import from. This includes Active Directory, LDAP directories and Business Data Catalogs. By default, a connection of type Active Directory is created within Import Connections, for the domain where SharePoint is installed. The default settings used by this connection are as follows:

Retrieving information from Active Directory source (Gatherer Phase)

1. Import process can be started manually or can be scheduled by an administrator.

2. Once started SharePoint begins the initialization phase by locating how many Import Connections are configured. A connection for the Domain where Farm exists is already created by default during SSP creation.

3. At the beginning of every import, the Indexer performs a DNS query in order to locate a domain controller of the domain (Using AutoDiscover) or picks up the DC specified on the connection. If we cannot obtain a connection to the DC, the system simply attempts to locate another domain controller within the same forest without throwing any errors. As a troubleshooting step for this phase, we could try using specific DCs in the import configuration if we can determine that is where the problem is using a network monitoring tool like Netmon.

4. After a domain controller is identified, we attempt to connect to it. The crawler component on the indexer loads the spsimport protocol handler shipped with SharePoint.

5. This first connection, which is anonymous, will provide SharePoint server, extra information about the DC it contacted. This includes various LDAP related information including its exact capabilities and the authentication mechanism it supports. This entry point is known as the “Root” or “RootDSE”.

6. If the AD requires authentication, which is by default the case, SharePoint will authenticate using the context of the Default Content Access Account or account configured on Profile import page.

7. The Indexer sends an LDAP Search Request to the DC using the "search base" & "User Filter" values specified asking for any match in the whole sub tree for user or group objects with attributes. Therefore, we can modify the search filter to suit our requirements – For example, we can use a search filter that imports only accounts that are enabled or that are in a specific organizational unit or even for a specific user.

8. SharePoint queries for 10 users at a time and therefore the Response received from the DC would be in bunch of 10 users. The Searchcontrol property as seen above specifies that.

9. SharePoint server would then perform a query for every object asking further attributes for that object. As seen below the search request is for a user named Tim Sanders & attributes queried are displayname, objectsid etc .

10. The data received in batches of 10.

11. Within the gatherer pipeline the iFilter is the first to handle the data. The iFilter extracts the data and hands the data chunks to the Archival & Retrieval plug-in.