Importing and Configuring User Profiles
The MOSS user profile database is empty OOB. MOSS provides two basic methods for loading user profiles: manually or automatically. Loading manually is not practical, so we’ll focus on MOSS’s automatic features.
Just like English is the common language of the business world, computer systems use a common language to talk to each other about user profiles. In MOSS’s case, that language is called Lightweight Directory Access Protocol (LDAP).
If you’re interested in a little more technical background on this, read on. Otherwise, skip this paragraph. LDAP’s particulars are well beyond the scope of this book, but for those interested, just try typing “ldap://[server]” in your Web browser and replace [server] with the name of your company’s LDAP server (try your e-mail server if you don’t know what that is). You’ll be prompted to “Find People” where you can search by name and e-mail address. LDAP is just another language, such as Spanish or Farsi, that computer applications use to communicate with each other. In this case, LDAP talks to directory services providers such as AD. Here’s a sample LDAP query:
(&(objectCategory=Person)(objectClass=User)(!(userAccountControl:1.2.84 0.113556.1.4.803:=2))(!(!givenName=*)))
This query basically says, “find me all the users in the repository who are active (that is, not inactive or disabled) whose first name is blank.” LDAP queries are not for the weak of heart. However, they are the most basic method MOSS uses OOB to retrieve user profiles. It’s important to understand how MOSS does this and your options so that you are able to retrieve user profiles in the first place and second, able to pull just those profiles that you really want to show up in MOSS.
Figure 7.1 shows how this all works together.
A MOSS SSP connects to AD and executes an LDAP Query. AD responds with a set of user profiles. MOSS creates profiles in its user profile database for each user returned by the query.
Alternatively, companies can populate the MOSS user profile database using custom code, as shown in Figure 7.2.
It’s even possible to import user profile data from multiple backend sources. For example, AD may be the official repository for information such as name, e-mail, and office number, whereas a custom HR application stores the user’s direct manager. By combining an LDAP query against AD with data pulled from another user profile repository using custom code, MOSS’s user profile can become the most authoritative source of user information in your organization.
As we can see, MOSS is flexible and provides many options for pulling data into the user profile database. Microsoft built this flexibility to address the real-world needs of large organizations. SharePoint recognizes that any given user’s information will be found in various places, not just AD. These places include line-of-business applications such as Enterprise Resource Planning (ERP) or Customer Relationship Management (CRM) and even a user’s own head (for example, his personal interests). MOSS’s ability to build a comprehensive user profile pulling data from these multiple systems means that it can become the one authoritative source of user information in the entire enterprise. In practical terms, this means that MOSS becomes a company directory. It serves as a basis for social computing functionality, defining audiences (explained later in this chapter) and allowing users to exert some control over how they are presented to the rest of the company by listing skills, interests, and so on.
Note that in both diagrams, the arrows show data flowing in just one direction. As you’ll see later in the chapter, users can modify their MOSS profile. However, those profile changes don’t replicate back to the official data store. There is nothing stopping an organization from implementing bi-directional updates. In fact, several third-party vendors have created and sell such tools, typically for password maintenance. However, it isn’t supported OOB.
| Many times, people are outright flummoxed by the fact that user profile updates aren’t bi-directional. However, once you consider the fact that user profile information lives in a multitude of systems, not just Microsoft’s own AD product, it becomes clearer. There are a lot of very odd directory services in the world. That said, it would certainly have been nice to allow bi-directional updates when the directory service is AD. |
The diagrams also show that user profiles are a shared service. This has a number of important practical implications, the most important being that user profiles, and all the functionality they provide in SharePoint, are available everywhere in the farm. Contrast this with site content types. Content types are defined for a specific site and are available to all child sites. In a given site collection, the root site is the highest possible level, meaning that content types can never be shared between site collections. This complicates information architecture overall. User profiles don’t suffer from this limitation.
That’s enough theory. Let’s relate this to SharePoint. System administrators manage user profiles via the SSP, in which they can do the following:
Define imports.
Schedule imports.
Map official user profile properties to SharePoint user profile properties.
Extend and customize SharePoint profile properties.
There are two kinds of imports: full and incremental. Full import deletes the user profile store in SharePoint and rebuilds it from scratch. Incremental import profiles search only for changed profiles.
| If a profile is deleted in the official profile store, SharePoint doesn’t immediately delete the profile in SharePoint. It takes a few passes before doing it. Sometimes, people think this is a security problem, but it isn’t. The official profile store is responsible to authenticate users. We don’t want SharePoint to remove all that user profile stuff because it’s useful for historical context. Just as you wouldn’t take a separated employee’s laptop and put it through a tree grinding device, we don’t want SharePoint to do the same thing with user profiles. |
System administrators manage profiles using the SSP, as shown in Figure 7.3 (the area outlined with a black box).
Bread-and-butter MOSS profile functionality lives under the User profiles and properties link. There are two broad categories of functionality here: Profile and Import Settings and User Profile Properties. Let’s examine each in turn.
Profile and Import Settings
Most readers of this book aren’t SharePoint administrators, so this section only covers the overall functionality here. It doesn’t go step by step and menu by menu through this section’s options. However, it’s important for IT professionals to understand the big picture and that’s what this section provides.
SharePoint administrators use the Profile and Import Settings functionality to tell SharePoint when and how to load user profiles. This is the starting point for the entire user profile experience in SharePoint.
The Profile and Import Settings screen is shown in Figure 7.4.
Figure 7.4 presents administrators with a summary of user profile activity, including the total number of user profiles SharePoint has loaded and manages, the status of the profile import, an indication that any errors may have occurred and then, at the bottom, a set of links that administrators use to manage the system.
To extract user profile data, administrators first define an import connection. SharePoint doesn’t define any connections OOB. Use the View import connections link to manage connections. This is where you supply that LDAP query as shown in Figures 7.1 and 7.2.
A trained AD administrator will understand these configuration options. MOSS allows administrators to specify the AD server, the port, whether to use Secure Sockets Layer (SSL) when connecting, and various other options. To do this, access the import settings by clicking on the link titled View import connections, as shown in Figure 7.4. Let’s pay particular attention to the import connection’s Search Settings shown in Figure 7.5.
It’s easy to make a mistake here. Watch out for the User filter option because the default user filter normally includes too many user profiles. It basically says, “pull every user into MOSS,” which causes several problems. First, it pulls disabled users from AD and may result in pulling users into MOSS who left the company years ago. Second, AD is often ... confusing. It’s not unusual to pull in devices, such as printers and computers, into the MOSS user profile database.
| If you’re live with MOSS already and used the default query, you may be wondering what happens if our LDAP query already pulls in too many user profiles or is broken in some other way. Unlike other potential mistakes, this is easily solved. Craft the LDAP query that makes the most sense for your company, and use it going forward. As MOSS executes the new query, it detects those changes. If the new LDAP query returns fewer profiles, it removes the incorrect profiles from MOSS. Note that only the profile is removed—other user information, such as membership in SharePoint security groups, “created by” on documents, and so on, is always retained. Those scenarios must be handled manually, outside of the profile import process. |
After the connection is defined, it’s time to use it. SharePoint allows us to define full and incremental import schedules. A full import executes the LDAP query and imports every user profile it finds into MOSS. An incremental import executes the same query but only imports those profiles that have changed since the last time a full or incremental import was run. Typically, companies configure SharePoint to run a full import once a week and an incremental import at least once a day.
Manually adding user profiles is the final key function of interest to IT professionals (see Figure 7.6). In addition to using LDAP to retrieve users in an automated fashion, SharePoint lets you create user profiles manually. You can create them individually, one by one. It would be unusual to manually enter many profiles. However, it can be useful for testing various business scenarios while your organization determines the best way to pull information from AD or other external membership sources. This function allows you to quickly enter some profile data and use SharePoint’s functionality without the overhead of a fully automated import.
Aside from providing a Web screen for adding users to MOSS’s database, this function also shows several key features that are described in greater detail in the next section.
Note that to add a user profile, the account must exist. The simple statement that “The account must exist” can become complicated in some environments, but it boils down to this: if that user can log in to the network, you should be able to manually create a profile for that user. Otherwise, you probably can’t.
User Profile Properties
The User Profile Properties screen is straightforward, as shown in Figure 7.7.
Figure 7.7. View user profile properties.
MOSS allows you to add new profile properties, view existing properties, and delete properties. A property is a piece of information about a user, such as the user’s name, office number, skill set, and so on. The User Profile Properties screen shown in Figure 7.7, from a default environment, shows that MOSS defines 46 properties for a user profile. This means that MOSS manages 46 discrete pieces of information for each user in its user profile database. MOSS allows you to view profile properties as well (see Figure 7.8). Properties serve as the basis for People Search and allow you to define audiences. Audiences are described in detail later in this chapter.
This is a rich MOSS function. Figure 7.8 shows that properties have a number of attributes. The most interesting attributes are as follows:
Property Name. The name of the property.
Property Type. For most properties, it defines the type of data stored in the property. Unfortunately for IT professionals, some of these types are very developer oriented. A type of “string” means that just about anything you can type using a keyboard is valid input for that type. Others are friendlier. For example, “Person” clearly means a reference to another user in the profile database.
Mapped Attribute. This is a tricky one. When MOSS successfully executes an LDAP query, it receives a list of user profiles and profile attributes in the LDAP language and specific to the directory service itself. In an AD environment, the user’s first name is contained in a field named “givenName.” This means that when MOSS runs the LDAP query, it creates or updates the user profile field “First name” using the value of “givenName” from AD. Note, however, that “About me” does not have any mapped attribute. This means that the “About me” is never updated automatically. You’ll learn more about this later.
Beyond My Sites, why should IT professionals care about user profile properties? One part of the answer is search. Any properly configured user profile property is easily searchable using standard MOSS search. Consider this frivolous business requirement. The CEO is an avid golf fan and wants to know every employee’s golf handicap. The CEO wants to be able to find potential golf partners based on this property. It’s easy to meet this requirement in MOSS. Simply add the custom property, have users update their golf handicap via their My Site (or have an administrator do it manually), and the system is ready to process the CEO’s search query.
Controlling User Profile Properties
As described earlier, MOSS builds user profiles by accessing user information from one or more user databases or storage areas and populates user profile properties. As we’ll see in the next section, MOSS lets users update their profiles. However, this can lead to a problem with authoritative profile sources. Your company may use a fully featured HR management system that tracks, among other things, every employee’s manager. We can configure MOSS to define a policy that prevents users from changing certain profile properties. We do this using the user profile services as shown in Figure 7.9.
Figure 7.9. Profile services policies.
Profile services policies allow you to specify the following:
Editability. Can a user edit this value via the My Site?
Privacy. Who is allowed to view this data? As we’ll see next, SharePoint displays users’ profile information on the public version of their My Site. Users control which information is available to whom based on their relationship with the My Site visitor. SharePoint supports the following relationships: managers, workgroups, colleagues, and everyone.
SharePoint administrators use this function to implement and manage data policies as they relate to My Sites. They allow a company to define rigid rules when needed but flexibility when it makes sense. For example, the HR system is the one and only authoritative source of information on manager relationships and employee job titles. On the other hand, employees can specify both their personal interests (for example, “Cat Lover”) as well as who is allowed to view those interests.
My Sites pulls all this together.