This section is intended to give you the commonly asked questions and answers when designing Shared Services for an intranet. The following scenario uses a single Intra-farm SSP, with a single index server. Most Intranet SharePoint Server 2007 deployments will leverage the functionality of My Sites, user profiles, search, and audiences.
My Sites provide a one-to-many collaboration space for your users. Many organizations shy away from My Site deployment because they want control over all of the collaborative space, and My Sites are not easily policed. Be aware that users tend to create a personal collaboration space, whether you allow it through a My Site or not. For example, any site collection administrator can create a subsite and grant access to that site. We have seen this many times when My Sites weren’t allowed. Site collection administrators simply created their own. Now you can’t find these personal collaboration sites because there is no standard in the creation or management. A better way is to embrace the technology and what is most likely a permanent shift in content management. That is, most technology is moving toward the data owner (the user) managing the life cycle of documents, including the creation of containers to host that content, and the delegation of authorization through permissions. Administrators will be tasked with building the high-level buckets that will contain this information. It is even possible that administrators may eventually control authentication only, and all authorization will be performed by the data owners themselves. Of course, there is something we can do to govern these personal collaboration spaces.
First, we can control the available permission to all My Sites by modifying the hosting Web application’s user permissions for Web application, as seen in Figure 16-14. This is possible only if you have followed the best practice of creating a My Site provider (Web application) for the sole purpose of hosting My Sites. Otherwise, changing permission levels and policies will affect your collaboration sites as well.
Figure 16-14. You can remove available permission levels from the My Site provider in Central Administration.
Second, and more powerful, is the ability to grant or deny permission explicitly to a set of users’ My Sites in a Web application. For example, you can remove the ability for contractors and temporary workers from creating subsites, using Web parts, and using the explorer view on libraries. Figure 16-15 shows the interface in Central Administration for creating Web application policies. Once again, you must have put My Sites in a dedicated Web application(s) to prevent modification of permissions on other site collections.
As you can see in Figure 16-15, you don’t have to apply permission changes to every user; you apply policy to users individually or via groups. You can also grant permissions to users, such as the Service Desk, that will override site collection permissions. You could create an auditing account that has read permissions on all My Sites. This account can then be used to monitor site collection usage and adherence to your Information Technology governance policy.
Third, you can extend and map the My Site provider to another zone. A zone is another URL that is associated with the same content databases. This allows you to modify permissions based on the entering URL, authentication, protocol scheme, and encryption. For example, you could extend the My Site provider http://my.contoso.msft to https://my-external.contoso.msft for Internet access to users’ My Sites. Based on the URL entered in the browser, you can grant or deny permissions such as SharePoint Designer usage and managing lists. The possibilities are almost endless for policy-based customizations using zones.
Fourth, you can have custom My Site definitions. In these custom site definitions, you can trim out functionality you do not want available in the My Site. Conversely, you can add functionality needed to meet requirements on a large scale.
You can surface information about your users through user profiles and the properties contained therein. These properties can contain any type of information, from a specific skill set to a user’s phone number. These properties can be imported directly from an LDAP, such as Active Directory, or gathered from the user in his or her My Site. An often overlooked option is gathering this profile information through a personal profile page when a user does not have a My Site. If a user doesn’t have a My Site, you can still see these properties via a people search.
A common misconception is that user profiles are used for authentication. They are not. User profiles are associated via the SID so that information can be surfaced in a site collection. You surface this information in a site collection by marking a property as replicable. To mark a property as replicable, go to the property from Shared Services Provider Administration/User Profiles and Properties/View/Add Profile Properties, then check Replicable on the pertinent property. To mark a property as replicable, it must be viewable by Everyone, and the user can not change the privacy setting. Figure 16-16 shows where to select the Replicable option.
A best practice for user profile properties that are being linked to an external source is not to allow users to change it on their details page. Allowing them to do so can be frustrating because they think they are permanently changing the property, but it is overwritten during the next import. Additionally, be sure to expose the property on the users’ details page if you want to collect information from them. Requiring them to fill out a property field but not exposing it on the details page is fruitless.
Note
Many properties do not import correctly with an incremental profile import. A best practice is to perform only full imports of user profiles. Profile information is lightweight, but you may need to dedicate a Domain Controller in very large environments.
There are some limitations to user profile imports. One of the most obvious, and quite limiting, is that you may have only one rule per LDAP import source. So, for example, you cannot import from two separate OUs in Active Directory. To target specific users in your Active Directory, you must use import filtering and Active Directory security. Simply remove access from the default content access to those objects you do not want imported into SharePoint Server 2007. When connecting to multiple LDAPs, be sure you have a common unique ID, or you could have multiple profiles per individual.
The earlier example of audiences was targeting News information to users who are in a specific group. This can be expanded in an enterprise to include almost anything. Here are some ideas for audience targeting:
Target content to users based on their division.
Target content to users based on their department or manager.
Alert users in specific buildings or geographic locations through audientized Web parts.
Target objects in a list, such as a calendar, to specific users. You can combine content type and site column filtering for a very relevant view to a group of users.
Remember that much of SharePoint Server 2007 is already security trimmed. So, for example, when users visit a site, they will see only the items in the quick launch that they can access. Similarly, users only see sites on a publishing top link bar that they have permissions to view. Take caution when adding links to the navigation manually as they are separate objects from the sites to which they link and therefore have unique security settings. Unless you create those links in a publishing site and leverage audiences, all users will see the link regardless of their ability to authenticate to the hyperlinked source.
When using SSP resources in the extranet, you should always thoroughly test your design. For example, anonymous users cannot use audiences, nor can you target only anonymous users. When creating extranet and Internet Web sites, it is wise to think through the design of your Search infrastructure. With all but a few Internet sites, and many extranet sites, you will want to create a second index to host information for the sole purpose of exposing content to the Internet. Note that you will need a second SSP to manage your external Index. You may also want to create different BDC connections for external users.