SharePoint 2010
Enabling Expertise Search & User Profile Replication in SharePoint 2010
I assume if we have enabled the Enterprise Regional Search in all the regional farm then enabling expertise search / people search is very simple by adding the sps3://contoso.com in the Content Source in Search Service application. The next crawl will index all the profile in the current User Profile Store. but the issue here is the other regional farm user my profile data like Skills, Project etc.. is not available in the current farm because they always update or access their profile in their regional my site. The same issue will occur in Central Enterprise search if we have provisioned one common enterprise search.
The above issue can be resolved by replicating the other regional user my profile date in to other regional farm and central farm.
- The EMEA farm my profile date should be replicate to AsiaPac and americas farm.
- The AsiaPac farm my profile date should be replicate to Americas and EMEA farm.
- The Americas farm my profile date should be replicated to AsiaPac and EMEA farm.
How we are going to achieve the above list of activities? Yes, we are going to use User Profile replication engine to replicate the my profile data between user profile services.
User Profile Replication Engine:
The User Profile Replication Engine is an optional component of Microsoft SharePoint Server 2010 and is part of the SharePoint Administration Toolkit. The User Profile Replication Engine enables an administrator of a User Profile Service application to replicate user profiles and social data, such as social tags, notes, and ratings, between User Profile Service applications. This replication can be one-way or bidirectional. For more information see User Profile replication engine.
Types of replication
The following table describes the differences between full replication, incremental replication, and recovery, all of which can be run by using the User Profile Replication Engine. For performance purposes, you can specify the maximum number of replication threads allowed on a server that is running the User Profile Replication Engine.
Type | When to use |
Full Replication |
|
Incremental Replication | After full replication is complete, start incremental replication within 14 days to make sure that individual changes are being detected and replicated. |
Recovery |
|
Can I User Full replication to achieve my goal?
No, The full replication is not required in our scenarios because all user profiles are imported from AD in all the regional Farm and we need to replication only the changes done by the end user via My site like Skills, school, project & etc..
In our scenarios we will be using Incremental Replication to replication the my profile date between the user profile service.
Incremental Replication:
Incremental replication also uses the trusted My Site host locations list to determine the My Site host location for a user. This identifies the primary profile for a user. The User Profile service that hosts the personal site for a user is also considered to have the primary profile record for that user. Audiences are used to identify and group related users and associate those users who have particular My Site hosts. For additional information about trusted My Site host locations, see Add or delete a trusted My Site host location (SharePoint Server 2010).
The incremental replication process depends on the trusted My Site host locations list to avoid cyclical replication. For example, if a user updates his or her AboutMe property in User Profile store A, the User Profile Replication Engine synchronizes that change to User Profile store B and the change log will capture that as a change. The instance of the User Profile Replication Engine running against User Profile Store B will attempt to replicate that same change back to the User Profile Store it came from (User Profile Store A) as something that changed since the last replication. However, before replicating it, the User Profile Replication Engine will check the trusted My Site hosts locations list to determine whether the user’s profile is the primary profile in the User Profile Store B. If it is, then the User Profile Replication Engine will replicate the change.
Power shell script to run the Incremental Replication
Start-SPProfileServiceIncrementalReplication : Replicates changes for selected profile properties from the source User Profile service application to the destination User Profile service application using the Replication Engine Windows service.
Start-SPProfileServiceIncrementalReplication -Destination <String[]> -Source <String> [-ActiveDirectoryDomains <String[]>] [-Credential <PSCredential>] [-DoSocialReplication <SwitchParameter>] [-DoUpgrade <SwitchParameter>] [-EnableInstrumentation <SwitchParameter>] [-FeedProperties <String[]>] [-MatchSubtype <SwitchParameter>] [-NumberOfRetry <Int32>] [-Properties <String[]>] [-ReplicationInterval <Int32>] [-Timeout <Int32>] [-WaitTimeBetweenFailures <Int32>]
Parameter | Required | Type | Description |
Destination | Required | System.String[] | Specifies the URL of the My Site Host to where the user profiles are replicated, for example, http://euro.contoso.com:8081/my. |
Source | Required | System.String | Specifies the URL of the My Site Host from where the user profiles are retrieved, for example, http://hq.contoso.com:8081/my. |
ActiveDirectoryDomains | Optional | System.String[] | Specifies the Active Directory Domain Services (AD DS) accounts to be replicated, for example, “headquarters” or “Europe”.The default value returns all AD DS domains. |
Credential | Optional | System.Management.Automation.PSCredential | Specifies the User Profile Replication Engine Windows service credentials the first time you run this cmdlet or anytime you want to change the Replication Engine service credentials. To get the User Profile Replication Engine Windows service credentials, use the Get-Credential cmdlet. For more information, see Get-Credential (http://go.microsoft.com/fwlink/p/?LinkID=113311). |
DoSocialReplication | Optional | System.Management.Automation.SwitchParameter | Enables replication of social tags, notes, and ratings. Only use this parameter when both the source User Profile service application and the destination User Profile service application are Microsoft SharePoint Server 2010-based. |
DoUpgrade | Optional | System.Management.Automation.SwitchParameter | Enables the replacement of invalid characters in the social taxonomy. This attribute must be used if the source is a Office SharePoint Server 2007 User Profile SSP and the destination is a SharePoint Server 2010 User Profile service application. |
EnableInstrumentation | Optional | System.Management.Automation.SwitchParameter | Enables detailed logging by using the instrumentation log. |
FeedProperties | Optional | System.String[] | Specifies that the trusted My Site host locations list should be ignored when replicating changes for the specified user profile properties. |
MatchSubtype | Optional | System.Management.Automation.SwitchParameter | Prevents mismatches between source and destination profile properties by using the destination profile properties as a filter. For performance reasons, we recommend that you only use this parameter if most of the user profile properties are mismatched between the source User Profile service application and the destination User Profile service application. |
NumberOfRetry | Optional | System.Int32 | Specifies the number of times that the User Profile Replication Engine should attempt to restart in the event of a failure, for example, a network disconnection. The default value is 10. |
Properties | Optional | System.String[] | Specifies which user profile properties to replicate, for example, “FirstName” or “AboutMe”. You can also use the Get-SPProfilePropertyCollection cmdlet to return a collection of all user profile properties. The default value returns all user profile properties. |
ReplicationInterval | Optional | System.Int32 | Specifies the amount of time, in seconds, between each replication iteration. The default value is 5. |
Timeout | Optional | System.Int32 | Specifies the amount of time the User Profile Replication Engine should wait for a response from the Web service before timing out. The default value is the Web service timeout. |
WaitTimeBetweenFailures | Optional | System.Int32 | Specifies the amount of time, in seconds, that the User Profile Replication Engine should wait after it fails to replicate a user profile before the Start-SPProfileServiceRecoveryReplication process begins. The default value is 300. |
Thee below script will replicate the my profile changes from EMEA farm to ASIAPAC and americas farm.
start-spprofileserviceincrementalreplication -source https://mysite.emea.contoso.com -destination [https://mysite.americas.contoso.com,https://mysite.asiapac.contoso.com%5D -EnableInstrumentation -Credential $mycredential -Properties “Specifies the list user profile properties to replicate”
This entry was posted in SharePoint 2010 and tagged Expertise Search, User Profile Replication.
Plan Global My site & User Profile Replication In Geographically Distributed SharePoint Farms
Introduction:
This article will provide you the steps to achieve the following in the geographically distributed sharepoint farms,
- Preventing individual users from creating multiple My Sites – Part 1
- Provisioning Expertise Search – Part 2
How end user can create multiple My site?
Let me describe a sample scenario with geographically distributed farms. In this scenario, users work in different regions, each of which uses a different UPS Application. Some users have to collaborate across regions, and must have access to multiple UPS Application. This is particularly common if an employee in a global deployment moves between geographic locations.
Suppose that, as usually, users of each farm are configured in the same forest. If you want to give users the possibility to see other users’ profiles you have to configure in each farm the import of profiles from Active Directory and if you want that users in a region can see profile of users of other regions you have to import all users profiles in each farm.
This works well and in each farm you can see all users details but what happen if you want to give users the possibility to update their details (like skills, blog site and so on)? Let me show you an example: MyLinks. MyUser1 is browsing a site collection located in Farm 1 and adds a shortcut to a page with MyLinks OOB functionality. This link is recorded in a property of the user profile on UPS application 1. If the same user MyUser1 goes to a different site collection hosted on Farm 2 and looks at the list of his links he cannot find the previous added link on Farm 1. This happens because of Farm 2 is using a different UPS Application 2 and user profiles are not synchronized between UPS APPs.
We have a similar behavior with My sites. Each UPS Application hosts My Sites, so if a user click on MySite link from a site on Farm 1 he is redirected to the MySite hosted on UPS APP 1 but if the same user click on MySite link from a site on Farm 2 he is redirected to a different MySite hosted on UPS App 2.
When planning for My Sites, you must consider the location of the users in the organization and the number of farms or User Profile service applications that will host My Sites. If you have more than one farm or User Profile service application, you will likely have to configure trusted My Site host locations.
Trusted My Site host locations
The Trusted My Site Host Locations feature prevents a user from creating more than one My Site in an organization with multiple User Profile service applications.
To prevent individual users from creating multiple My Sites, configure trusted My Site host locations. When specified, users are redirected to the single My Site host location that is intended for their accounts regardless of where they are browsing when they attempt to create or access their My Sites. This feature ensures that each user can create only one My Site in an organization.
Geographically distributed farms
The following diagram illustrate the geographically distributed SharePoint farms
- The User profiles are imported from all the available domain in the root directory
- User Profile service applications are configured individually in all the regional farm
- My sites are provisioned individually in all the user profile server application
Configuration & Interface Behavior
Step 1: The following target audience should be created & compiled in all the user profile service application. For More information see Manage audience
- Americas Regional Users
- EMEA Regional Users
- AsiaPac Regional Users
Step 2: The following Trusted My Site Host Locations should be added in all the user profile service applications with target audience
Trusted My Site host location | Target Audience |
https://mysite.americas.contoso.com | Americas Regional Users |
https://mysite.emea.contoso.com | EMEA Regional Users |
https://mysite.asiapac.contoso.com | AsiaPac Regional Users |
This below picture illustrates my site behaviour for a user belonging to EMEA Region after implementing the above configurations.
- When EMEA Regional User accessing the My Profile page from Site or My site in EMEA farm, he is able to view is my site in https://mysite.emea.cotoso.com and he can view or edit his profile.
- When EMEA Regional User accessing the My Profile page from Site or My site in Americas farm, he is able to view/ redirected to his regional my site in https://mysite.emea.cotoso.com and he can view or edit his profile.
- When EMEA Regional User accessing the My Profile page from Site or My site in AsiaPac farm, he is able to view/ redirected to his regional my site in https://mysite.emea.cotoso.com and he can view or edit his profile.
- When EMEA Regional user trying to view other regional user profile in EMEA farm, the my profile page will be redirected to other regional farm where the user belongs to.
How it works:
When EMEA regional user access the my site in Americas domain the User profile service in Americas will look for current logged in users target audience and corresponding trusted host url and then it will redirect the user to appropriate Mysite.
I will cover the “Enabling Expertise Search & User Profile Replication” in my next post. Thanks.
This entry was posted in SharePoint 2010 and tagged Expertise Search, MySite, User Profile Replication.
Windows PowerShell Out-Performing Stsadm Scenario
The Developer needs to activate a feature across 5,500 site collections. By using Windows PowerShell to run the Stsadm command, he came up with the following script to automate the work:
foreach ($site in (get-spsite -limit 5000000 -Webapplication $WebApp))
{
Write-Host “Activating feature ” $solutionName “on” $site.url “…”;
Write-Host stsadm “-o activatefeature -url” $site.url “-filename” $featureFileName;
stsadm -o activatefeature -url $site.url -filename $featureFileName
if( $lastexitcode -ne 0 )
{
Write-Host “Something went wrong activating the site feature. Exit code: ” $lastexitcode “`n” – ForegroundColor Red;
$failure = $true;
$error.Clear();
}
}
When he ran the script in her test environment, he found it took more than 12 hours to run. The Developer then decided to look for a better way of doing things. After talking to Grant, he found out there was built-in cmdlet to do this exact task. he then tried this script:
Get-SPSite –Limit ALL –WebApplication $WebAppNameorUrl |%{ Enable-SPFeature $FeatureIdOrName –url $_.Url }
The script ran in less than one hour. Lesson learned: If Stsadm.exe can do the operation, Windows PowerShell can do it too, and generally more efficiently.
This entry was posted in SharePoint 2010 and tagged PowerShell.