WHAT YOU WILL LEARN IN THIS CHAPTER:
The difference between user access and personalization
The different permission levels in a SharePoint site
SharePoint site groups and the built-in ones you can use
How to update user profile information manually and automatically
How to create audiences based on specific memberships or profile properties
How to target information and web parts to specific audiences
So far in this book, you've read a lot about how to work with SharePoint content and the various components you can create and customize. Unfortunately, none of your work with these topics means anything unless your users can quickly access that content, and configuring access to that information has a lot to do with how much of it there is and where it's located. Just because users have access to content does not mean that they have a requirement to see the content. It's important to evaluate the content that will be stored in your information system and determine how users will need to access and view it. You may need to do this by asking some important questions: Do you have too little information? Do you have so much information that a user can't wade through it? Where is your information located? Do you have one location in which to store information or do you have information located throughout a hierarchy? Can users easily access the information they need to perform their jobs? Is the content they view relevant to them?
After reading this chapter, you should feel comfortable planning and implementing changes to your SharePoint environment to ensure that users can access content relevant to them.
Before you learn how to manage access to any SharePoint site, you need to understand two very important concepts in SharePoint related to the users who connect to your sites:
Understanding these concepts helps you learn how to effectively manage a site, protect the site's integrity from users who shouldn't have access to certain information, and make the user experience as productive and problem-free as possible.
Imagine you work for a company where users from around the globe share information related to their various business activities. There are different divisions such as Sales, Marketing, Finance, and Legal. Members of a specific division can log in to their portal site and stay up to date on projects and initiatives, as well as work with others in their divisions and teams. For this to happen effectively, you must configure the SharePoint environment to support the following:
User access management: These are the rules that determine what a user can do on a site. To ensure that users can only access the content they need to perform their work, you apply permissions to each divisional site. Within a specific division, users may have different roles and privileges. For example, some users only view content, while others can add or approve new content.
Personalization: This ensures that content is relevant to the users of a site. You use personalization and audience features to do this. Personalization is allowing users to only view content that is relevant to them. You may accomplish this by providing them the ability to customize the interface to only display items that are of interest to them, or it may mean creating certain views that only display items where a person's username is displayed in a specific column, such as the Assigned to column. In some cases, you may want to target specific content elements, such as a document, list item, or web part, to members of a role. Through audiences, you can identify the groups of people that would find information relevant as you publish it. Perhaps in the Sales division, for example, certain promotions and sales procedures are only relevant for the North American region, and are distracting to sales personnel from the other regions. Therefore, when publishing these promotional documents, the content manager would select a North American audience.
Before you try to personalize content, it's very important that you solidify the underlying content access. With that in mind, the chapter covers user access features of SharePoint first, and then discusses audiences and other personalization features in greater detail.
When users click a link or enter the web address of a SharePoint site, they are either logged in to the site automatically because they are already authenticated on the site due to the configuration of their network or they are prompted for a username and password via a dialog box or form. In some cases, there may be no need for authentication because the site is configured for anonymous access. For this chapter, you will primarily review scenarios where the user is connecting in an authenticated environment.
Once users are logged in to the site, they will only see content and user interface elements that they have been given permission to view. The content that users view and edit is determined by their SharePoint site group membership and permission levels. Site groups are specific roles in SharePoint that determine what a user can do within a site. Permission levels define the activities that a user or group is allowed to perform in a specified location.
Note
For more on the different site groups and permission levels, see the section "Working with Site Groups and Permission Levels."
Most organizations using SharePoint in a corporate or enterprise setting, such as an intranet, will use Active Directory to manage user profiles and determine how users log in to the network, which is also known as the authentication process. If your organization uses Active Directory, SharePoint becomes a great browser-based tool in which to work because a user who logs in to the domain does not typically need to enter credentials again to access a SharePoint site. This is because when the system administrator configured the SharePoint server, it was added as a member of your Active Directory domain. Therefore, when you enter your username and password to connect to the network, the SharePoint environment will recognize you as a member and, therefore, not require you to specify your username and password again. In addition, SharePoint will allow you to connect to sites based on your site group membership and will retain your permissions as you access various other Windows-based systems such as file shares or printers. Most users prefer this type of experience because it can be tedious and confusing to manage both multiple usernames and passwords.
A site manager can add specific Active Directory users to a site group by typing their names or email addresses into the site membership interface. See Figure 10-1 for an example of how this can work.
However, in organizations with thousands of users, it's more realistic to add Active Directory security groups to a SharePoint site group. This not only reduces administrative overhead when you first set up a site but also means the site's membership stays up to date as new users join or leave the organization. As you add users to the Active Directory security group, they are automatically assigned to the SharePoint site group that has been associated with the security group, as shown in Figure 10-2.
The rest of this chapter looks at specific access and authentication examples based on an underlying assumption that Active Directory is the primary membership store.
TRY IT OUT: Sign In as a Different User
In this Try It Out, you've already logged in to a site with a user account and need to sign in as a different user with a different username and password. Depending on how your organization is using SharePoint, you may have entered login information when you first accessed the site, or you may be automatically logged in because your organization is using Active Directory.
Signing in as a different user can be helpful in scenarios where you must troubleshoot access issues for another user. It is always a helpful practice to have test user accounts configured for common user roles.
From the home page of your intranet site collection created in the first chapter of this book, expand the menu containing your name, as shown in Figure 10-3. This menu is known as the Personalization menu.
Select Sign in as Different User. A login box appears.
Enter the credentials of the user you want to log in as.
Click OK. You now see the name of the user you logged in as in the Welcome menu.
How It Works
The capability to sign in as a different user is important when you start applying special access settings or configurations to your environment and you need to validate your configurations by logging on under test user accounts. For example, if the members of the sales team group for your site should not have access to a specific document library, you can set up a test user account in the sales team group and log in as that user to confirm that the library is not accessible. Also, if you support an environment and users claim that they cannot perform a specific action or see a particular menu item, you can log in as a test user with the same access rights as that user to troubleshoot the problem.
As your SharePoint environment starts to become populated with important business documents, it's important to manage access properly. Users who require information to do their jobs should be able to easily locate and then access information. In cases where you have sensitive information on the portal, it's crucial that only users who have a business requirement to access it have the rights to do so. Finally, because SharePoint will become a central storage location for important business information, it is critical that this information be protected. This means locking out those who could cause harm to the system or should not have access to information.
A permission level represents a set of rights that can be assigned to a user or group on a specific SharePoint object such as site, list, or document. Out of the box, several permission levels exist to reflect the most common usage scenarios of the system; however, you can create custom permission levels to meet your specific requirements.
Note
It is not recommended to ever change the out-of-the-box permission levels; rather, create new permission levels to match your specific needs. By modifying the out-of-the-box permission levels you may run the risk of creating an environment that is difficult to identify and control exactly what rights users have.
The table below outlines the default out-of-the-box permission levels in SharePoint 2010.
TRY IT OUT: Create a Custom Permission Level
In certain cases, you may wish to assign a set of rights that isn't completely covered by the out-of-the-box permission levels in SharePoint. For example, you may wish to allow users to read and write, but you may not wish to allow them to delete items. Therefore, the Contribute permission level will not be suitable for your requirements. In this Try It Out, you will create a new permission level by copying the Contribute permission level and making modifications to the new permission level to suit your requirements.
From the top-level site of your site collection, select Site Settings from the Site Actions menu.
Select Site Permissions from the User and Permissions group of links. You will be redirected to the Permissions management page, as shown in Figure 10-4.
Select Permission Levels from the Ribbon.
Select the Contribute permission level. You will be redirected to a page containing the various rights and activities allowed within the Contribute permission level.
Scroll to the bottom of the page and click the Copy Permission Level button. A new blank permission level will be created containing the same settings as the Contribute permission level.
Enter Collaborate as the name for the new permission level.
Enter the following for the description:
Can read and write but cannot delete.
Deselect the options to Delete Items and Delete Versions.
Scroll to the bottom of the page and Click Create. Your new permission level will now be displayed within the permission level listing, as shown in Figure 10-5.
How It Works
The Contribute permission level contained rights similar to those you wished to provide the end users of your site, except for the fact it allowed users to delete items. Since you do not wish to allow users to delete documents or list items, you created a custom permission level called Collaborate. Rather than create everything from scratch, you created the Collaborate permission level from a copy of the Contribute permission level and removed the rights for deleting items and versions. Your new permission level is now available for use within your site and its subsites.
A SharePoint site group defines the membership of a specific role within an organization. The following list shows the different types of site groups that SharePoint has to offer out of the box. Depending on which site you create, you may notice all of these groups or a subset of them. However a better practice in real-life scenarios is to create custom groups that reflect your organization's structure.
Now that you have an understanding of the various SharePoint site groups and permission levels, let's take a look at some of the ways you can manage access to the content stored with sites by working with the site groups and permission levels. This section looks at how you can create your own site groups as well as change the access rights of a user or group by changing their existing permissions. You also learn how to control how users request access changes related to your site.
In the next Try It Out, you will create a site group called Employees to represent the employees of your organization, and you will assign the newly created permission level to that group. You then add new team members to your site group. If you find later that you need to change permissions on a group or user that you've already created, or totally remove a user altogether, you learn to do so in the third and fourth Try It Outs. In the last Try It Out of the section, you find out how to enable access to a site when a user requests it.
TRY IT OUT: Create a New Site Group
From the top-level site of your site collection, select Site Settings from the Site Actions menu.
Select People and Groups from the Users and Permissions group of links. You will be redirected to the Group Management area of the site. By default, you will be viewing the membership of the Site Members group.
Select the Groups link from the left-hand navigation menu. You will be redirected to the Groups listing page.
Select the option to create a New Group from the New menu of the toolbar. You will be redirected to the Create Group page, as shown in Figure 10-6.
Enter Employees for the name of the group.
Enter the following description into the About Me field for the group:
Site group for Adventure Work employees
For this example, you should enter your name for the Group Owner value. However, it is a best practice to create a SharePoint Administration group and specify that group as the owner for all other SharePoint groups.
Retain the default configurations for Group Settings and Access Requests.
For the Give Group Permission to this Site section, select the Collaborate permission level. This will give all members of the Employees group collaborate access to the site.
Click Create.
How It Works
When you create your group, you automatically become a member because you are the creator. The next step is to add new team members to your site groups. You do this in the next Try It Out.
TRY IT OUT: Add a User to a Site Group
In this example, you will add a special group known as "Authenticated Users" to your new SharePoint site group. This will ensure that any user who has successfully authenticated to your network will have access to your intranet site. In some cases, this may not be appropriate if you have users who have access to your overall network, but you do not want to give them access to SharePoint. In such a case, it would be more appropriate to specify an Active Directory group that represents all the employees of your organization. It is good practice to plan such group membership choices with the appropriate members of your organization's security team.
Note
You may run into situations where the people responsible for managing a SharePoint environment may not be experts in the Active Directory group structure that another administrative group establishes. To prevent this, whenever two groups plan a new SharePoint environment or site collection, they should consult each other to ensure permissions are assigned in a way that benefits the entire organization and minimizes administrative overhead.
From the top-level site of your site collection, select Site Settings from the Site Actions menu.
Select People and Groups from the Users and Permissions group of links. You will be redirected to the Group Management area of the site. By default, you will be viewing the membership of the Site Members group.
Select the Employees link from the left-hand navigation menu. You will be redirected to the Employees Membership page, as shown in Figure 10-7.
Select the option to Add Users from the New menu of the toolbar. The Grant Permissions window will appear, as shown in Figure 10-8.
Click on the Address book icon to launch the user and group search interface.
Search for the term "users." You will receive a listing of results that contain the term users.
Select the Authenticated Users group, and click the Add button.
Click OK. The Authenticated Users group will now appear in the Grant Permissions window.
Click OK. You will be returned to the Group Membership page.
How It Works
Using the Authenticated Users group ensures that as new employees are added to the organization, they are automatically provided access to the SharePoint sites with which the Employees group has been associated. This provides a more seamless access management environment and helps standardize access across groups.
TRY IT OUT: Modify the Permissions of an Existing User or Group
In some scenarios, it's necessary to change the specific rights that a single user or site group has on a site. This may be related to a direct request from a business manager, a change in requirements or perhaps because you need to grant a certain user rights to a workspace beyond what he or she currently has. This may be because the user has demonstrated exceptional skills and would make a good candidate to assume more responsibility for managing the SharePoint site. In the next example, you see the process for identifying and modifying the group membership and site permissions of a single user.
From the top-level site of your site collection, select Site Settings from the Site Actions menu.
Select Site Permissions from the Users and Permissions group of links.
Select the checkbox associated with the Employees group, as shown in Figure 10-9.
Select the Edit User Permissions option from the Ribbon.
Deselect the Collaborate option and select the Read permission level.
Click the OK button. You will be returned to the Site Permissions page, where you will see the Employees group now has Read access to the site.
How It Works
In the preceding example, you changed the permissions associated with the Employees group from Collaborate to Read. This may be because of a recent requirements change to limit the access rights of all employees and to limit the number of employees that had the ability to update information within the intranet.
TRY IT OUT: Remove a User from a Group
When you created the Employees group, your username was automatically added as a member of that group. Since you are already a member of the Authenticated Users group, there is no need to also have your user account individually assigned to the group. Therefore, you will remove it from the group using the following procedure.
From the top-level site of your site collection, select Site Settings from the Site Actions menu.
Select People and Groups. You will be redirected to the Group Management area of the site. By default, you will see the membership of the Site Members group.
Select the Employees link from the left-hand navigation menu.
Select the checkbox to the left of your name from the membership listing.
Select the Remove Users from Group option from the Actions menu. You will receive a warning message, as shown in Figure 10-10.
Click OK to confirm your action and complete the operation.
TRY IT OUT: Enable Site Access Requests
So far, you've seen tasks that you, a site owner, can complete to assign access to team members or groups. However, certain situations may require that users request access to a site. For example, a user might click a hyperlink to a site of which he or she is not a member. SharePoint has a built-in access management feature that allows users to request access via the web interface by clicking a Request Access link.
From the top-level site of your site collection, select Site Settings from the Site Actions menu.
Select the Manage Access Requests link. A window will appear, as shown in Figure 10-11.
Select the Allow request for access checkbox.
Enter the email address that all access requests should be sent to. It is good practice to use a distribution list for this address rather than a single user's email address.
Click OK.
How It Works
When users that do not have access to the site attempt to visit the address, they will be presented with a page similar to the one shown in Figure 10-12.
From this page they may request to be added to the membership of the site. This method has several benefits including:
Users can request access without having to access another tool or interface: The system automatically provides all the information that is required to effectively address the request and routes the request to the appropriate individual responsible for the site. This is the person (or group of people) associated with the email address specified in the previous steps. This saves both parties valuable time and is a benefit in large organizations that use ticket-tracking systems to provide such access.
The user requesting access does not know who is responsible for the site: It discourages people from going around a defined methodology and using more direct access request methods such as telephone or manual email, which could be potentially more time-consuming and distracting.
Everything you've learned so far has been related to controlling access and rights on a SharePoint site. However, SharePoint also supports permissions management on the list and item level. This means that, while a user may contribute to his team's collaborative site, he may only be a reader for a particular document library or even a single document in a library. This section discusses the different levels of access that you can have on a SharePoint site.
Each of the examples thus far in this chapter has applied to managing access at the site level because, by default, this is the level where access is defined. From a restriction standpoint, you do not want to overcomplicate access and you want to keep things simple unless your requirements dictate otherwise.
When you work on a site level, you need to determine whether you want a subsite to inherit permissions from a parent site or not. Your decision generally depends on your requirements:
Inheriting permissions: When you inherit permissions from a parent site, you create a scenario in which any user who has permission to the parent site will have the same permissions and rights on the child site. This cuts down on the tasks and effort associated with managing permissions and creates a consistent access experience for all users.
Creating unique permissions: Creating a site with unique permissions will allow you to manage permissions and access to your child site, independent of the settings specified for the parent site. Therefore, a user who can add content on the parent site may not necessarily have access to the child site. Users perform different roles from site to site. This means that you'll have to spend more time setting up and managing the site, but you will have greater flexibility in meeting the access requirements of each individual team. Sometimes it's beneficial to give users greater access rights on a subsite than they have on a parent site. For example, in a sales proposal workspace, members of the sales team may be able to create lists and libraries to aid in their production of the proposal, whereas on the sales team site they may only have permissions to add content to existing lists.
TRY IT OUT: Stop Inheriting Permissions from a Parent Site
You may have created a site and selected the option to inherit permissions from the parent, but at a later time, realized you needed to manage the site's permissions independently of the parent site. The following example uses the project site that you created in Chapter 2 and assumes that the site has different usage requirements than your main intranet site. You change the permissions settings on the existing site, which copies all permission settings from the parent into the project site so that you can manage them separately.
Remember that if users have permissions on the parent site and you do not want them to have access to the project site, you must remove them after breaking the inheritance because SharePoint copies the permissions, groups, and users from the parent into the child. You wouldn't have to do this if you had not selected to inherit permissions when you first created the site. In that case, once the site is created, it has a blank set of permissions, and no users of the parent have access to the site unless explicitly given access. The exception, of course, is a site collection administrator or site owner on the parent site.
Note
If you did not complete the exercises from Chapter 2, you can create any subsite on your site collection that inherits the permissions of parent. The same steps apply regardless of what site template you use.
From the main page of the Project Gros Morne site, select Site Actions from the Site Settings menu.
Select Site Permissions.
Click the Stop Inheriting Permissions option from the Ribbon.
You will receive a warning message, as shown in Figure 10-13.
Click OK to confirm your action. The page will refresh and a yellow message bar will appear at the top of the screen, indicating that the site has unique permissions.
How It Works
Once you selected the option to stop inheriting permissions, the users, groups, and permissions from the main intranet site were copied down into the project site. You may now make additional changes such as removing groups or adding users. Any changes you make to the project site will not have any impact on the main intranet site.
Sometimes a list or library on a team site requires a different set of permissions than the rest of the site. For example, a document library containing sensitive financial performance reports should not be shared with everyone who has access to the site. You could create a separate site to store this information, but it's easier to simply adjust the permissions on the library so that a subset of users can access the library. Another example is where only certain users can edit a specific list or library in which team members can only view content. For example, only a manager can create new items on an Announcements list for a team, but team members can contribute to list and libraries on the rest of the site.
TRY IT OUT: Assign Unique Permissions to a List
In this Try It Out, you modify the permissions on an announcements list so that only members of the Approvers group can create new content. Even though all other site members can add content to other lists, it is important that you restrict the Announcements to only allow Approver members to add new items. To accomplish this, you must stop inheriting permissions on the Announcements list from the site. Similar to the scenario in the previous Try It Out, when you stop inheriting permissions for a list from a site, all rights are copied from the site into the list, so you must update the settings to reflect your requirements. For this exercise, you use the Project site from the last Try It Out, which has unique permissions from its parent.
From the main page of your Project site, select the All Site Content link from the side navigation.
Select the Announcements list.
Select the List Settings option from the List tab of the Ribbon.
Select the Permission for this list link. You will be redirected to the Permissions Management page for the list.
Click the Stop Inheriting Permissions option from the Ribbon.
You will receive a warning message.
Click OK to confirm your action. The page will refresh, and a yellow message bar will appear at the top of the screen indicating that the list has unique permissions, as shown in Figure 10-14.
Select all groups except the Approvers group, and click the Edit User Permissions option from the Ribbon.
Select the Read permission level, as shown in Figure 10-15.
Click OK.
How It Works
When you disconnect from the permissions of the site, all rights and users are copied to the permissions scheme for the Announcements list. Therefore, you must edit the rights of each group and user so that they can only read items. You selected every group and changed their rights to Read-Only, but then deselected the Approvers group so that its members could edit content. Note that the Site Owners group or any other group with Full Control to the site can still add content, and you cannot remove this group from a specific list or library.
By default, access to an individual list item is inherited from the list or library in which it resides. However, you may need to better define this. For example, storing a policies and procedures document within a team's shared documents library means anyone can contribute to it and add contents; however, for legal reasons, only certain managers should have the right to edit it. You can restrict access to one document, even if it resides in a list or library to which everyone has access, as shown in the next Try It Out. In a second Try It Out, you learn how to limit access to a list so that users may only view or edit items that they have created themselves.
TRY IT OUT: Assign Unique Permissions to a Document
In this Try It Out, you create a new document and restrict the rights so that only members of the Approvers group have the access to edit the document.
From the main page of the team site, select Shared Documents from the Quick Launch bar.
Click the New Document option from the Document tab of the Ribbon.
Save the document with a filename of Team Policies and Procedures.docx.
Hover over the document with your mouse and select the Manage Permissions item from the drop-down menu, as shown in Figure 10-16.
The Manage Permissions page for the document appears. Select the Stop Inheriting Permissions option from the Ribbon. The page will refresh and a yellow message bar will appear at the top of the screen indicating that the site document has unique permissions.
How It Works
In this example, you created a new document that had slightly different requirements over all other documents in the library. Rather than place it in a unique location, it's far more effective to manage the rights of this document independently of the library and make the required changes on an item-by-item basis.
Note
While you just learned the steps for securing items individually in your environment, you should always confirm the necessity of such configurations as the more uniquely secured items that exist within your environment, the higher degree of management and control that will be required to support them. It is highly recommended that you avoid uniquely secured items unless absolutely required by your business scenario.
TRY IT OUT: Customize Item-Level Access Rights on a List
You can uniquely apply permissions to documents or list items in the same way as in the last Try It Out. However, lists also have a unique function that allows for a site manager to determine if users can view or edit their own items or the items of others. For example, it may be helpful to allow team members to view each other's appointments. However, a user should not be allowed to edit appointments belonging to a coworker. In the following example, you modify the default settings of the Calendar list so that users can view, but not edit, a coworker's items. You can do this on SharePoint lists but not with documents stored within document libraries.
From the main page of your project site, select Calendar from the side navigation.
Select List Settings from the Calendar tab of the Ribbon.
Select Advanced Settings. The Advanced Settings page for the list will appear as shown in Figure 10-17.
In the Item-level Permissions section, for Read access, keep the default value that users can Read all items.
In the Item-level Permissions section, for Create and Edit access, select the option that users can Create items and edit items that were created by the user.
Click OK.
SharePoint Server has a special database that can store information about the users of the system, called the user profile database. This database contains properties and metadata about each user of the system in a very similar manner to that in which you can store information describing a document in a document library. User profile information is useful for storing contact information and biographies of the different users of the system for information-sharing purposes, but you can also use it for more advanced purposes, such as content targeting and personalization via audiences (discussed in a later section of this chapter).
While SharePoint can import profiles from other sources, this chapter assumes that Active Directory is your primary profile source because it is the most common identity store for organizations using this application. SharePoint maps user profile properties to common profile properties from Active Directory, including Name, Email Address, Phone Number, Manager, and Address. SharePoint can also import custom profile properties such as skills, languages, and employee ID.
In addition to importing information from Active Directory, SharePoint can obtain user information from the following sources that can augment user profiles with additional information:
User profiles are not required for an organization to implement SharePoint; however, they allow you to personalize information, including profile information to share with coworkers. For example, each SharePoint user can create a My Site, where he or she can store personal or shared files, view organizational content, write a personal weblog, and maintain his or her own profile properties. You can create a personal site by selecting the My Site link from the personalization menu of any page or site in the portal, as shown in Figure 10-18.
Each My Site has an area known as My Profile, where users can share information about themselves. By sharing more details on personal sites and profiles, workers can get to know each other better, which helps in situations where employees work for the same company but in different buildings.
From the Public Profile page, you can view a variety of information about an employee including:
An image of the employee
Contact information
Documents that the employee has shared
Information on who the employee reports to and any other employees who report to them
Things that the employee has in common with you based on profile properties such as languages, skills, or schools
Tags and Notes that the user has created
Colleagues
An example of a public profile page is shown below in Figure 10-19.
Because profile properties are indexed and searchable, you can search for a specific property and find a list of people who have that property assigned to them. For example, if you are a manager looking for a computer programmer with ASP.NET experience to build a custom web part for your SharePoint site, you can use the People search scope to search for ASP.NET to receive a list of people in your organization who have that skill. When you click their names, you are redirected to their personal site, where you can find out who their manager is (in case you want to contact the manager) and what previous projects the employees have worked son.
Although you can import some profile properties from primary membership systems such as Active Directory, users can update others themselves via their My Site. This helps keep information up to date and relevant. The server administrator decides what profile properties a user can update. A user can also select from the following choices on who can view information that is stored in specific properties:
For example, something such as skills or schools would be shared with Everyone, while a home phone number would only be viewable by a manager. The following Try It Outs illustrate how users can update their own profile properties via their personal site. In the event you have a specific detail that you want a user to provide on the site, for example, specific professional experience, certification, or attended business seminars, you can add a new user profile property.
Many of the remaining exercises of this chapter are based on the assumption that you are working in a SharePoint Environment where the User Profile Server Application has been configured for use. Please confirm with your system administrator that this has been configured properly. While this topic is considered outside the scope of this book, details related to the configuration of this Service Application are available here: http://technet.microsoft.com/en-us/library/ee721050.aspx
TRY IT OUT: Update a User Profile
In this Try It Out, you update all profile properties that you have access to edit, noting that you cannot edit some profile properties such as your manager or your account name. Generally, the information that you cannot edit is imported from a central directory or application dedicated to storing such information.
Updating profile properties is only a small fraction of what you can do from your personal site, but it's a great way to familiarize yourself with your personal site and will keep your personal information up to date. All information entered into a user's profile is saved.
From the home page of your corporate site, click the My Profile link from the Personalization menu, as shown in Figure 10-20.
Select the Edit My Profile link. The Edit Profile page will appear.
Complete all missing information in your personal profile.
For the Home Phone field, change the Show to drop-down value to My Manager.
Click Save and Close.
TRY IT OUT: Add a New User Profile Property
In the last Try It Out, you updated common profile properties. In addition to those properties, you can add new profile properties that users can update on their own. For example, you can add a property to allow users to specify what certifications they have attained, as the following steps show. Because users may have more than one certification, you should allow for multiple values. Because not every user may want to specify that information, you can make it optional.
From the main page of the Central Administration site, select the Manage service applications link.
Select the User Profile Service Application item from the listing, as shown in Figure 10-21, and click the Manage option from the Ribbon. You will be redirected to the Manage Profile Service page.
Select the New Property option. The Add User Profile Property page will appear, as shown in Figure 10-22.
Complete the information as follows:
ITEM
VALUE
Name
Certifications
Display Name
Certifications
Type
String (MultiValue)
Length
25
Multivalue Separator
Comma: A,B,C,...
Sub-type of Profile
Default User Profile Subtype
Description
List any professional certifications you have received
Policy Settings
Optional
Default Privacy Setting
Everyone
Edit Settings
Allow users to edit values for this property
Display Settings
Select these three options:
Show in the profile properties section of the user's profile page
Show on the Edit Details page
Show updates to the property in newsfeed
Search Settings
Select the Indexed box
Click the My Profile link from Personalization menu.
Select the Edit My Profile link.
Scroll to the bottom until you see the custom property you created for Certifications. Update this with any certifications you have attained, and click the Save & Close button.
How It Works
In this Try It Out, you specified that the property should be indexed because this may be a value for which someone might want to search. For example, when a business manager prepares to launch a major new project for an upcoming product launch, she may want to search for someone who has a project management certification such as PMP. By searching for this item, she can find employees with this qualification and review their experience on past projects to discover who might be a perfect match to manage this new project.
You import user profiles into SharePoint on a scheduled basis and can do so from single or multiple sources. In cases where you are importing profile information from more than one database, you must have a master connection, which is either Active Directory or another LDAP server and a secondary connection, which isa Business Connectivity Services application.
You configure connection synchronization settings from the Manage Profile Service page. You can access this site from the Manage Service Applications page by selecting the User Profile Service Application and clicking the Manage button from the Ribbon.
If no synchronization connection exists, you must create a new connection under the Configure Synchronization Connections link, as shown in Figure 10-23.
From the Manage User Permissions section, you may specify permissions for a variety of personalization services, such as:
Create personal site
Use personal features
Use social features
An audience is a special group to which content is targeted so that only people in that audience see it. A user becomes a part of an audience based on profile properties or membership to a distribution list or SharePoint site. Audience content targeting should not be confused with access. Just because users cannot see an item does not necessarily mean that they do not have access to the item. An audience may exist for members of an organization that work out of a certain region such as Canada. Therefore, if you assign the audience to an announcement related to a special event taking place at the Canadian office, it will be seen only by members of that audience. The following sections give some examples of how you can use audiences.
You can configure certain web parts such as the Content Query web part, discussed in Chapter 7, to support audience filtering. This means that when you display multiple items in a web part, users will only see those that are targeted to them. Figures 10-24 and 10-25 demonstrate examples of filtering list information by audience via a Content Query web part. Figure 10-24 is what the team site main page looks like to a member of the sales team audience, who can view the Sales Strategy document because it's targeted to their audience. Figure 10-25 shows the same site page as viewed by someone who is not a member of the sales team audience. Notice the user does not see the Sales Strategy document even though it exists in the library.
If the user who isn't in the sales team audience were to click the Shared Documents library, he or she could still see the document listed in the view, as shown in Figure 10-26. This is because the Content Query web part filters items so that they are only displayed to targeted audiences and the standard list web parts are not. All web parts, however, allow you to target the contents of an entire web part to an audience.
More than likely, your organization has already made significant investments in Active Directory, which groups people based on their roles as well as the organization's communication requirements. So instead of creating audiences, which you need to manage and maintain as an extra layer in the SharePoint environment, you can take advantage of existing objects, such as Windows Distribution Lists or Security Groups. In fact, your organization probably has a distribution list on your Exchange mail server for the sales team that keeps them informed of product updates and sales promotions. You can use the distribution list as an audience and target content from the SharePoint environment directly to the audience's members. As announcements are added to the corporate portal, the audience can see and, thus, view the latest news as soon as they log on. If the organization is fairly busy and generates numerous new announcements each day, the use of audiences helps users "separate the wheat from the chaff."
The next two Try It Outs show you the process of managing a membership-based audience. The first Try It Out shows you how to target an item to a distribution list so your audience can keep up to date on new promotions and other information via a central portal page. This is useful for sales teams, who, because they travel and work remotely, have limited time and need to view content directly related to them. The next Try It Out shows you how to target specific list items, documents, or even entire web part content to an audience by creating audiences based on membership to SharePoint site groups.
TRY IT OUT: Targeting a List Item to an Audience
You can target specific news and announcements to an audience. This allows members to keep up to date on new promotions and sales tactics when they visit a central portal page that contains a web part that supports the use of audiences. Other team members cannot view the announcement in this example when they visit the same page, although they still have access rights to view it if they want to. This page may contain updates for many other groups and divisions, so by effectively using audiences to target content to users based on their roles, you help ensure that content is limited to only what is relevant to users.
From the main page of your project site, select the View All Site Content item from the Site Actions menu.
Select the Announcements list.
Select Audience Targeting Settings. You will be redirected to the Modify List Audience Targeting Settings page.
Click OK.
Click the Announcements link from the breadcrumb navigation trail.
Click the Add new announcement link.
Enter the following information into the list item form:
For the Target Audiences column, select the Browse button. The Select Audiences dialog appears, as shown in Figure 10-27.
Search for and select the Approvers group from the SharePoint Groups and click the Add button.
Click OK to complete your audience selection.
Click Save to save the announcement to the list.
How It Works
Once you have configured audiences for the list, you can add a Content Query web part to the main page of your team site and query the announcements list using the method described in Chapter 7. You can then select the option to apply audience filtering, as shown in Figure 10-28.
TRY IT OUT: Target a Web Part to an Audience
You can target specific list items, documents, or even entire web part content to an audience. In this example, you target a list web part that displays items that are pending approval to the SharePoint site group responsible for approving content. If you add the web part to the main page with a listing of all pending items as the default view, Approvers are more likely to respond in a timely manner. An example of this is a web part on the main page of a site that highlights items pending approval. Because these items are relevant only to members of the Approvers group, you select this audience on the web part to ensure that only they can see the web part on the main page. While other team members can still access the documents, no action is required from them, so the web part would only be a distraction.
From the main page of your project site, select Shared Documents from the side navigation.
Select Library Settings from the Library tab of the Ribbon. You are redirected to the settings page for the document library.
Select Versioning Settings. You are redirected to the library's Version History Settings page.
Select Yes for Require Content Approval for Submitted Items.
Click OK.
Return to the main page of your site by clicking the Team Site link in the navigational breadcrumb trail.
Add the Shared Documents web part to the page using the method described in Chapter 7.
Select the Shared Documents web part, and click the Web Part Tools tab from the Ribbon.
Change the selected view to the Approve/Reject Items view. You may receive a pop-up window warning that you may lose changes made to the view. Click OK to continue.
Expand the Advanced properties pane.
From the Target Audiences field at the very bottom of the web part pane, select the Browse button. The Select Audience dialog box appears, as shown in Figure 10-29.
Select SharePoint Groups from the Find drop-down, enter Approve in the search box and click the Search icon to the right of the box that resembles a magnifying glass.
Select the Approvers group.
Click Add.
Click OK on the Audience selection window.
Click Apply, and then click OK on the web part.
Click Exit Edit Mode on the main page.
How It Works
In this Try It Out, the pending status of documents is of no interest to team members other than the Approvers group. To other members, it might be distracting and take up valuable real estate. Sometimes by effectively using audiences on web parts, you can fit a greater deal of content on a page, yet avoid unnecessary clutter on each user's screen by limiting the number of web parts he or she sees.
All examples of the audience creation process so far have been based on either Active Directory or SharePoint-based groups. This chapter now discusses how audiences are created based on properties from the user profiles. When you consider that the profile can contain information not only from Active Directory (or another LDAP server) but also from other business applications, such as a human resources or financial database, you can see that the possibilities for how specifically you can target content are endless. By using personal profile properties, you can make audiences very detailed to the point of defining audiences for specific topics. For example, you can create a profile property called News and Promotions that has a value list from which users can select via their profile to identify what products they want to receive promotional updates on.
In the following example, you see how to create an audience based on the property you created earlier in the chapter for certifications in the Try It Out "Adding a New User Profile Property." If you recall, this field gives users a place to update their own certifications from their My Site. However, it is equally as possible for you to automatically update this profile property from an external system, such as Active Directory or a central human resources database.
TRY IT OUT: Create an Audience Based on User Profile Information
In this Try It Out, you create a rules-based audience that checks the certifications profile property and compiles the members who have a project management certification. Because this is an audience where you expect membership changes over time, you will base membership on a profile property that you know users will keep up to date on their own, rather than manually identifying and updating membership within a specific Active Directory group, distribution list, or site group.
From the main page of the Central Administration site, select the Manage service applications link.
Select the User Profile Service Application item from the listing, and click the Manage option from the Ribbon. You will be redirected to the Manage Profile Service page.
Select the New Audience button from the toolbar. You will be redirected to the Create Audience page, as shown in Figure 10-30.
Enter a name for the audience. This example uses Certified Project Managers.
Enter a description for the audience. For this example, enter the following:
This is an audience that represents all employees who have attained a project management professional certification.
Enter your own name for the owner of the audience.
Select the option to include users who satisfy any of the rules.
Click OK. The Add Audience Rule window appears, as shown in Figure 10-31.
Because this audience is based on a user property, select Property for Operand.
Select the Certifications profile property from drop-down.
Select Contains from the Operator selection box.
Enter PMP for value.
Click OK. You will be returned to the View Audience Properties page.
Click the Compile Audience link to complete the process. Any users who have completed their user profiles and included PMP as a certification will now be placed within the new audience. Each time the audience compiles, it will query all profiles and add or remove members based on the changes made since the last update.`
This chapter discussed two important concepts related to information management: user access and personalization. User access is the way you can control who can view, edit, or create content in a SharePoint environment. You can define access on the site level, document library, or list level through permission levels and site groups. For lists, you can also define rules for what content users can read or edit at the item level.
As a general rule, you should use existing Active Directory groups and objects when you assign permissions to specific roles in a SharePoint group. In most organizations, Active Directory is kept up to date as employees change positions, leave, or are hired. By creating a relationship between Active Directory and SharePoint site groups, you automatically keep user membership current without relying on manual updates.
Personalization in SharePoint is delivered via functions such as user profiles, audiences, and My Sites. When you use personalization features, users are only exposed to content that is relevant to them. Profile properties and My Sites also help encourage users to learn more about each other and interact with one another. In many organizations, users do not connect with one another because of a lack of awareness of what they have in common with one another or who has what skills.
When defining personal profile properties, users can determine if everyone, their colleagues, their manager, teams, or only the user can view information. This helps create a network of professional and personal information sharing that is controlled and secure so that users feel comfortable sharing specific details and know that these details will only be shared with the appropriate audience.
This chapter also discussed how you can create audiences to identify groups of users who share common profile properties, group memberships, or characteristics. Once an audience is created, content from the SharePoint site can be targeted at them. The more audiences are used for content, the more relevant the user experience becomes.
WHAT YOU LEARNED IN THIS CHAPTER
TOPIC | KEY CONCEPTS |
|---|---|
What is a SharePoint Group? | A SharePoint group is a role defined to which users can be added. These groups can then be assigned specific rights and permissions to different elements within SharePoint. |
What is a Permission level? | A permission level is a set of rights that can be assigned to a user or group in SharePoint. |
What is an Audience? | An audience is a group of people that share common characteristics. Content or web parts may be targeted at specific audiences so that when members of that audience view a page, the content will be visible to them but not to users that are not members of the audience. This helps create a relevant user experience for site members as they only see information that has been targeted to their role. |