Showing posts with label SharePoint 2013. Show all posts
Showing posts with label SharePoint 2013. Show all posts

Thursday, July 21, 2016

You cannot use SharePoint. Your system administrator has turned off the feature. Outlook 2013

When the user tries to connect to outlook from SharePoint calendar, then below error appears.

"You cannot use SharePoint. Your system administrator has turned off the feature".

Microsoft Windows SharePoint Services features are turned on in Microsoft Office Outlook 2013. In cases where administrators do not want their Outlook 2013 users to have access to Windows SharePoint Services features, it is possible to turn off these features.
Warning If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.

Solution:
1. Run REGEDIT
2. Go to HKEY_CURRENT_USER/Software/Microsoft/Office/15.0/Outlook/Options/wss
3. Double-click on the disable and set the Value data to 0 (0 for enable and 1 for disable) click ok.

Configure Sitemap in SharePoint 2013

In SharePoint 2013, we have native support for generating XML sitemaps which was not present in the earlier versions of SharePoint. Sitemaps basically inform the search engines about the pages and their metadata, present in your site. This help the crawlers in picking up those pages. This is a great feature especially for public facing websites.
There are three prerequisites for generating sitemap:
  1. This feature is available for publishing sites only.
  2. Anonymous access should be enabled for both web application and site collection.
  3. Search should be configured in the environment.
The step by step procedure to generate sitemap is:
1. Enable anonymous access for web application. For this go to “Central Admin” -> “Manage Web Applications” . Select your web application and click on “Authentication Providers” in top ribbon. Click on the zone. There you will get the option to enable anonymous access.


2. Enable anonymous access for site collection.
Go to “Site Settings” -> “Site permissions”. Click on “Anonymous Access” in the top ribbon and select “Entire Web site”. Click “OK”


3. Activate “Search Engine Sitemap” feature of site collection. This registers a timer job “Search Engine Sitemap Job” for generating sitemap. This job by default runs daily.


4. As sitemap generation uses Search Service to generate sitemap; run full crawl or incremental crawl as applicable to your environment. 
Go to “Central Admin” -> “Application Management” -> “Manage service applications” -> “Search Service”.
Then click on “Content Sources” and run full/incremental crawl for your content source.

5. For getting instantaneous result, run the timer job "Search Engine Sitemap Job" mentioned in step 3 for your web application manually.

6. And we are done.


The sitemap is located at the root level site collection. The url to access the sitemap is http://<WebApp>/sites/<SiteColl>/sitemap.xml. This file contains the location of actual sitemap and that is http://<WebApp>/sites/<SiteColl>/sitemap0.xml. The content of the sitemap file is like: 

And if we need to display the site map for multiple sites, then follow the above steps for each site collection, then the site map will be generated for those sites also.
Hope this helps.

Thursday, July 14, 2016

Infopath Error: The form template is browser-compatible, but it cannot be browser-enabled on the selected site

When we set the InfoPath to open in the browser by setting the following properties.

Form Options -> Compatibility -> Web Browser Form


And also the Form Library Settings to Open in browser.

 And when we try to publish the InfoPath form, then it will give the below warning message.

"The form template is browser-compatible, but it cannot be browser-enabled on the selected site"


In order to avoid this error, make sure that the site collection feature "SharePoint Server Enterprise Site Collection features" is enabled.


 When it is enabled, then we will not get this warning message.

 

Tuesday, July 12, 2016

Infopath Issue: Web page cannot be displayed

Recently when we have upgraded from SharePoint 2007 to SharePoint 2013, we have found one strange issue with opening the InfoPath Forms.

When we try to edit the InfoPath template by going to the Form Library -> Advanced Settings, then it thrown the below error as "Webpage cannot be displayed".


This issue occurs for one user who is trying to open the form in InfoPath 2010 version. This issue didn't occur for the users who has the InfoPath 2013 version.

I found the below blogs which are helpful to resolve the issue.

https://social.msdn.microsoft.com/Forums/exchange/en-US/c47561bd-d7f0-441f-bc27-3b6e1f0457a0/cannot-view-infopath-form-on-sharepoint-2013-since-i-removed-skydrive-for-business-and-installed?forum=sharepointcustomization

https://blogs.technet.microsoft.com/office_integration__sharepoint/2014/02/24/the-webpage-cannot-be-displayed-when-trying-to-openedit-an-office-file-from-a-sharepoint-2013-site/

In the first article, they have mentioned to change the registry key.

So, please follow the below steps to change the registry key.

Go into the registry by typing regedit from the Run line and rename the SharePoint.OpenDocuments.5 key (ex. SharePoint.OpenDocuments.5.old) under HKEY_CLASSES_ROOT.


 

Monday, July 11, 2016

Issue with Email address/Sending Email in Infopath Form

If the user tried to send an email through the Send Email Data Connection, where we specify the To/CC field mapped to a 'DisplayName' from the person or group field in the InfoPath Form.

It works most of the time, but I have seen there are some users whose email address is not resolved and so it always throws error that its not able to find the email address of that user.

This issue occurs if the user has an account in more than one domain, then they get this error message. User who have only one account in intranet domain, their account name resolves and email is sent.

Please check the below blogs talking about the same issue.

https://support.microsoft.com/en-us/kb/968479

http://answers.microsoft.com/en-us/ie/forum/ie11-iewindows8_1/the-form-cannot-be-submitted-because-some-of-the/549e5d02-3402-4209-a3ed-ca82ef3a4805?auth=1

To resolve this issue, get the email address of the user from the person or group field using user profile service and give that email address field in the Send Email Data Connection.


Name of the Requestor Email Address text box is C070EmailAddress.

Name of the Requestor people picker field is C070Group

For the "Get Email" button, add the rules as shown below.

Here the first action is Set a Field's value.
Here the AccountName is from the User Profile web service data connection.

 
 
And here the "AccountId" is the AccountId from the C070Group people picker field.
 
 
 
Next action is "Query for Data" and here select the "GetUserProfileByName" data connection.
 
 
 
Next action is a Set Field's value. Here Set the "C070EmailAddress" text box field value with the WorkEmail which got retrieved from the user profile web serivce data connection.
 
 
 
Here is the step on how to get the value of the WorkEmail for that user.
 

 

 
Then save the rule. When you preview the form, if you enter the user in the people picker box (C070Group), and click on button "Get Email", then it will retrieve the email address for the entered user from the user profile.

 

Issue with UserGroup Service in Infopath Form

When InfoPath give the error as "Unable to connect to the web service.
http://sharepoint.daks.com:1111/sites/InfoTest/_vti_bin/UserGroup.asmx?WSDL

This issue occurs if the user is not able to see the membership of the group.

Check the below article.

http://www.infopathdev.com/forums/p/23009/79618.aspx

Because i was using the GetUserCollectionFromGroup to check a user's membership in a group, I needed to enable the option in the SharePoint group to allow everyone to view the group membership.  Once I turned that on, it appears that my users are no longer getting the error message.  Now that I've fixed it, it seems to make sense...how can you check if you're a member of a group if you can't see the group membership?
Hopefully this will help someone else out somewhere down the line.

Thursday, October 16, 2014

Create and Configure Search Service Application in SharePoint 2013 using PowerShell



The core search architecture of SharePoint 2013 has a more complex and flexible topology that can be changed more efficiently by using Windows PowerShell. Each Search service application has its own search topology. If you create more than one Search service application in a farm, it’s recommended to allocate dedicated servers for the search topology of each Search service application.

In this blog, we will see how to configure topology for one search service application with multiple search components across 2 servers for redundancy and performance.

#==============================================================
#Search Service Application Configuration Settings
#==============================================================

$SearchApplicationPoolName = " SearchApplicationPool"$SearchApplicationPoolAccountName = "Contoso\Administrator"$SearchServiceApplicationName = "Search Service Application"$SearchServiceApplicationProxyName = "Search Service Application Proxy"$DatabaseServer = "2013-SP"$DatabaseName = "SP2013 Search"$IndexLocationServer1 = "D:\SearchIndexServer1"mkdir -Path $IndexLocationServer1 -Force$IndexLocationServer2 = "D:\SearchIndexServer2"mkdir -Path $IndexLocationServer2 -Force

#==============================================================
#Search Application Pool
#==============================================================

Write-Host -ForegroundColor DarkGray "Checking if Search Application Pool exists"$SPServiceApplicationPool = Get-SPServiceApplicationPool -Identity$SearchApplicationPoolName -ErrorAction SilentlyContinueif (!$SPServiceApplicationPool){ Write-Host -ForegroundColor Yellow "Creating Search Application Pool"$SPServiceApplicationPool = New-SPServiceApplicationPool -Name$SearchApplicationPoolName -Account $SearchApplicationPoolAccountName -Verbose}

#==============================================================
#Search Service Application
#==============================================================

Write-Host -ForegroundColor DarkGray "Checking if SSA exists"$SearchServiceApplication = Get-SPEnterpriseSearchServiceApplication-Identity $SearchServiceApplicationName -ErrorAction SilentlyContinueif (!$SearchServiceApplication){ Write-Host -ForegroundColor Yellow "Creating Search Service Application"$SearchServiceApplication = New-SPEnterpriseSearchServiceApplication -Name$SearchServiceApplicationName -ApplicationPool $SPServiceApplicationPool.Name-DatabaseServer $DatabaseServer -DatabaseName $DatabaseName}Write-Host -ForegroundColor DarkGray "Checking if SSA Proxy exists"$SearchServiceApplicationProxy = Get-SPEnterpriseSearchServiceApplicationProxy-Identity $SearchServiceApplicationProxyName -ErrorAction SilentlyContinueif (!$SearchServiceApplicationProxy){ Write-Host -ForegroundColor Yellow "Creating SSA Proxy"New-SPEnterpriseSearchServiceApplicationProxy -Name$SearchServiceApplicationProxyName -SearchApplication$SearchServiceApplicationName}

#==============================================================
#Start Search Service Instance on Server1
#==============================================================

$SearchServiceInstanceServer1 = Get-SPEnterpriseSearchServiceInstance -local Write-Host -ForegroundColor DarkGray "Checking if SSI is Online on Server1" if($SearchServiceInstanceServer1.Status -ne "Online") { Write-Host -ForegroundColor Yellow "Starting Search Service Instance" Start-SPEnterpriseSearchServiceInstance -Identity $SearchServiceInstanceServer1 While ($SearchServiceInstanceServer1.Status -ne "Online") { Start-Sleep -s 5 } Write-Host -ForegroundColor Yellow "SSI on Server1 is started" }

#==============================================================
#Start Search Service Instance on Server2
#==============================================================

$SearchServiceInstanceServer2 = Get-SPEnterpriseSearchServiceInstance -Identity
"2013-SP-AFCache" Write-Host -ForegroundColor DarkGray "Checking if SSI is Online on Server2" if($SearchServiceInstanceServer2.Status -ne "Online") { Write-Host -ForegroundColor Yellow "Starting Search Service Instance" Start-SPEnterpriseSearchServiceInstance -Identity $SearchServiceInstanceServer2 While ($SearchServiceInstanceServer2.Status -ne "Online") { Start-Sleep -s 5 } Write-Host -ForegroundColor Yellow "SSI on Server2 is started" }

#==============================================================
#Cannot make changes to topology in Active State.#Create new topology to add components
#============================================================== $InitialSearchTopology = $SearchServiceApplication |
Get-SPEnterpriseSearchTopology -Active
$NewSearchTopology = $SearchServiceApplication | New-SPEnterpriseSearchTopology

#==============================================================
#Search Service Application Components on Server1#Creating all components except Index (created later)
#==============================================================

New-SPEnterpriseSearchAnalyticsProcessingComponent -SearchTopology
$NewSearchTopology -SearchServiceInstance $SearchServiceInstanceServer1 New-SPEnterpriseSearchContentProcessingComponent -SearchTopology
$NewSearchTopology -SearchServiceInstance $SearchServiceInstanceServer1 New-SPEnterpriseSearchQueryProcessingComponent -SearchTopology
$NewSearchTopology -SearchServiceInstance $SearchServiceInstanceServer1 New-SPEnterpriseSearchCrawlComponent -SearchTopology $NewSearchTopology
-SearchServiceInstance $SearchServiceInstanceServer1
New-SPEnterpriseSearchAdminComponent -SearchTopology $NewSearchTopology
-SearchServiceInstance $SearchServiceInstanceServer1

#==============================================================
#Search Service Application Components on Server2.#Crawl, Query, and CPC
#==============================================================

New-SPEnterpriseSearchContentProcessingComponent -SearchTopology
$NewSearchTopology -SearchServiceInstance $SearchServiceInstanceServer2 New-SPEnterpriseSearchQueryProcessingComponent -SearchTopology
$NewSearchTopology -SearchServiceInstance $SearchServiceInstanceServer2 New-SPEnterpriseSearchCrawlComponent -SearchTopology
$NewSearchTopology -SearchServiceInstance $SearchServiceInstanceServer2


Server1
Primary
Server2
Primary
IndexPartition 0
IndexComponent 1

True
IndexComponent 2
False
IndexPartition 1
IndexComponent 3
False

IndexComponent 4

True
IndexPartition 2
IndexComponent 5

True
IndexComponent 6
False
IndexPartition 3
IndexComponent 7
False
IndexComponent 8

True



#==============================================================
#Index Components with replicas
#==============================================================

New-SPEnterpriseSearchIndexComponent -SearchTopology $NewSearchTopology
-SearchServiceInstance $SearchServiceInstanceServer1 -IndexPartition 0
-RootDirectory $IndexLocationServer1

New-SPEnterpriseSearchIndexComponent -SearchTopology $NewSearchTopology
-SearchServiceInstance $SearchServiceInstanceServer2 -IndexPartition 0
-RootDirectory $IndexLocationServer2

New-SPEnterpriseSearchIndexComponent -SearchTopology $NewSearchTopology
-SearchServiceInstance $SearchServiceInstanceServer2 -IndexPartition 1
-RootDirectory $IndexLocationServer2

New-SPEnterpriseSearchIndexComponent -SearchTopology $NewSearchTopology
-SearchServiceInstance $SearchServiceInstanceServer1 -IndexPartition 1
-RootDirectory $IndexLocationServer1

New-SPEnterpriseSearchIndexComponent -SearchTopology $NewSearchTopology
-SearchServiceInstance $SearchServiceInstanceServer1 -IndexPartition 2
-RootDirectory $IndexLocationServer1

New-SPEnterpriseSearchIndexComponent -SearchTopology $NewSearchTopology
-SearchServiceInstance $SearchServiceInstanceServer2 -IndexPartition 2
-RootDirectory $IndexLocationServer2

New-SPEnterpriseSearchIndexComponent -SearchTopology $NewSearchTopology
-SearchServiceInstance $SearchServiceInstanceServer2 -IndexPartition 3
-RootDirectory $IndexLocationServer2

New-SPEnterpriseSearchIndexComponent -SearchTopology $NewSearchTopology
-SearchServiceInstance $SearchServiceInstanceServer1 -IndexPartition 3
-RootDirectory $IndexLocationServer1

#==============================================================
#Setting Search Topology using Set-SPEnterpriseSearchTopology
#==============================================================
Set-SPEnterpriseSearchTopology -Identity $NewSearchTopology

#==============================================================
#Clean-Up Operation
#==============================================================
Write-Host -ForegroundColor DarkGray "Deleting old topology"
Remove-SPEnterpriseSearchTopology -Identity $InitialSearchTopology
-Confirm:$false
Write-Host -ForegroundColor Yellow "Old topology deleted"

#==============================================================
#Check Search Topology
#==============================================================
Get-SPEnterpriseSearchStatus -SearchApplication $SearchServiceApplication -Text
Write-Host -ForegroundColor Yellow "Search Service Application and Topology
is configured!!"
$Server02 = (Get-SPServer "2013-SPHost2").Name
$EnterpriseSearchserviceApplication = Get-SPEnterpriseSearchserviceApplication
$ActiveTopology = $EnterpriseSearchserviceApplication.ActiveTopology.Clone()
$IndexComponent =(New-Object Microsoft.Office.Server.Search.Administration.Topology.IndexComponent
$Server02,1);
$IndexComponent.RootDirectory = "D:\IndexComponent02"



# Server1 is the local server where the script is run.

For fault-tolerance we need to have at least two index components (replicas) for an index partition. Here I create 4 index partition with 8 index components. One index partition can serve up to 10 million items. As a good practice, the primary and secondary replicas should be balanced among the index servers. So we will have Server1 hosting 4 index component (out of which 2 will be primary replicas) and Server2 hosting other 4 index components (2 primary replicas).



* Please note that above cmdlets will not create the primary replicas in the server we want as expected as we are running all the cmdlets at same time without saving the topology. Ideally we should create an index partition in one server and then run Set-SPEnterpriseSearchTopology. This will ensure that the primary replica is created in the server we want. The next time you run the same cmdlet in another server for same index partition will create secondary replica. For more details - http://blogs.technet.com/b/speschka/archive/2012/12/02/adding-a-new-search-partition-and-replica-in-sharepoint-2013.aspx

When the above script is run one after the other to create multiple index partitions and replicas in different servers, you can see in the picture below there is no particular order for creation of replicas in the servers. The Primary and secondary replicas are not created in the servers that we wanted. If you are concerned about primary index component server location, then you should set the topology before you run the cmdlet to create secondary replica in another server.






Now that all search components are created in our new topology. Before setting our new topology we need to activate this topology. Remember that we also have an old topology which is in active state.



We will use Set-SPEnterpriseSearchTopology cmdlet which does some important tasks - Activates the NewTopology [$NewSearchTopology.Activate()], deactivates all other active topologies and sets the NewTopology(Active) as the current Enterprise Search Topology

#==============================================================
   #Setting Search Topology using Set-SPEnterpriseSearchTopology
 #==============================================================
 Set-SPEnterpriseSearchTopology -Identity $NewSearchTopology

After running Set-SPEnterpriseSearchTopology cmdlet, it will look like



As Set-SPEnterpriseSearchTopology has already done most of the job for us we will do one last thing - delete the old topology as its no longer required.

#==============================================================
                 #Clean-Up Operation
 #==============================================================
 Write-Host -ForegroundColor DarkGray "Deleting old topology"
 Remove-SPEnterpriseSearchTopology -Identity $InitialSearchTopology
 -Confirm:$false
 Write-Host -ForegroundColor Yellow "Old topology deleted"


When $SearchServiceApplication | Get-SPEnterpriseSearchTopology cmdlet is run, you will find just one topology (new topology that we created)



#==============================================================
                 #Check Search Topology
 #==============================================================
 Get-SPEnterpriseSearchStatus -SearchApplication $SearchServiceApplication -Text
 Write-Host -ForegroundColor Yellow "Search Service Application and Topology
 is configured!!"

In Central administration, Search service application you will find topology like this;



In your environment to know the numbers for each search components, use this scaling guidelines.



* The New-SPEnterpriseSearchIndexComponent requires folder for storing index files. In multiple server search configuration scenario, New-SPEnterpriseSearchIndexComponent checks the existence of RootDirectory in the wrong server. It checks the existence of the folder only in the machine where PowerShell script is executed; even in those cases when new index component is scheduled for other machine. You will get an error message, New-SPEnterpriseSearchIndexComponent : Cannot bind parameter 'RootDirectory'

There are 2 workarounds for this;

1. Create the folder manually in the machine that runs powershell script as its done in the aforementioned script.

2. Use directly the SP Object model instead of cmdlets.

$Server02 = (Get-SPServer "2013-SPHost2").Name
 $EnterpriseSearchserviceApplication  = Get-SPEnterpriseSearchserviceApplication
 $ActiveTopology = $EnterpriseSearchserviceApplication.ActiveTopology.Clone()
 $IndexComponent =(New-Object Microsoft.Office.Server.Search.Administration.Topology.IndexComponent
 $Server02,1);
 $IndexComponent.RootDirectory = "D:\IndexComponent02"
 $ActiveTopology.AddComponent($IndexComponent)

* A note on removing an index component - If you have more than one active index replica for an index partition, you can remove an index replica by performing the procedure Remove a search component in the article Manage search components in SharePoint Server 2013. You cannot remove the last index replica of an index partition using this procedure. If you have to remove all index replicas from the search topology, you must remove and re-create the Search service application and create a completely new search topology that has the reduced number of index partitions.





Monday, October 13, 2014

Verify database upgrades in SharePoint 2013



Verify upgrade status for databases

You can use the following methods to verify upgrade:
  • Use the Upgrade Status page in Central Administration
    This page lists all farm, service, or content database upgrades and their statuses. This includes a count of errors or warnings.
  • Review the log files to look for errors or warnings
    If upgrade was not successfully completed, you can view the log files to find the issues, address them, and then restart the upgrade process.

Review the log files for database attach upgrade

To verify that upgrade has succeeded, you can review the following log and error files:
  • The upgrade log file and the upgrade error log file.
    Review the upgrade log file and the upgrade error log file (generated when you run the upgrade). The upgrade log file and the upgrade error log file are located at %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\15\LOGS. The logs are named in the following format: Upgrade-YYYYMMDD-HHMMSS-SSS.log, where YYYYMMDD is the date and HHMMSS-SSS is the time (hours in 24-hour clock format, minutes, seconds, and milliseconds). The upgrade error log file combines all errors and warnings in a shorter file and is named Upgrade-YYYYMMDD-HHMMSS-SSS-error.log.

Check upgrade status for databases

The Upgrade Status page lists the upgrade sessions and gives details about the status of each session — whether it succeeded or failed, and how many errors or warnings occurred for each server. The Upgrade Status page also includes information about the log and error files for the upgrade process and suggests remedies for issues that might have occurred.
To view upgrade status in SharePoint Central Administration
  1. Verify that you have the following administrative credentials:
    • To use SharePoint Central Administration, you must be a member of the Farm Administrators group.
  2. On the Central Administration home page, in the Upgrade and Migration section, click Check upgrade status.

Validate the upgraded environment

After you determine whether upgrade was completed successfully, validate your environment. Review the following items:
  • Service applications
    • Are they configured correctly?
    • Are the service application proxies configured the way that we want?
    • Do we have to create new connections between farms?
  • Site collections
    • Are sites that were not upgraded working as expected in 2010 mode?
    • Are all features associated with the sites working?
  • Search
    • Run a crawl, and review the log files.
    • Run search queries, and verify that the queries work as expected and provide appropriate results. Twenty-four hours later, view the query reports and look for issues.
    • Search for people and profiles.
    • Check any Search customizations to make sure that they work as expected.

User Access issue after upgrading the SP 2010 site to SP 2013

Users coming from a SharePoint 2010 system that try to access SharePoint 2013 after a migration receive a “this site has not been shared with you” message. This mean that they are not able to authenticate to SharePoint 2013.

In SharePoint 2013 there is a new authentication mechanism called Claim based authentication. Be default through the UI all Applications are created in this mode.

I created a PowerShell script that loops through all of your SharePoint 2013 web applications and upgrades each one to claim’s based authentication.

Script:
 Param(
    [string]  $account = $(Read-Host -prompt "UserAccount")
    )
Add-PSSnapIn Microsoft.SharePoint.PowerShell

foreach ($wa in get-SPWebApplication)
{
    Write-Host "$($wa.Name) | $($wa.UseClaimsAuthentication )"
    #http://technet.microsoft.com/en-us/library/gg251985.aspx
    $wa.UseClaimsAuthentication = $true
    $wa.Update()
    $account = (New-SPClaimsPrincipal -identity $account -identitytype 1).ToEncodedString()
    $zp = $wa.ZonePolicies("Default")
    $p = $zp.Add($account,"PSPolicy")
    $fc=$wa.PolicyRoles.GetSpecialRole("FullControl")
    $p.PolicyRoleBindings.Add($fc)
    $wa.Update()
    $wa.MigrateUsers($true)
    $wa.ProvisionGlobally()
}

For more information, refer the msdn blog: http://technet.microsoft.com/en-us/library/gg251985.aspx

Sunday, September 28, 2014

Configure Crawl Sources in sharepoint 2013

How to start a full crawl in Central Administration
Before you can start a full crawl in Central Administration, you have to specify which content source should be crawled. When you run a full crawl, all content in the content source is crawled even if that content has already been added to the search index.
For this scenario, we'll crawl the Local SharePoint sites content source.
  1. Go to Central Administration --> Manage service applications --> Search Service Application -- > Content Sources.
  2. On the Manage Content Sources page, hover over the Local SharePoint sites content source, and select Start Full Crawl from the menu.

The status of the crawl is shown in the Status column.
  1. Refresh this page until you see that the value in the Status column is Idle.
    This means that the crawl has finished.

  1. Optionally, you can verify that your items have been added to the search index by clicking Crawl Log.
    In our scenario, we now have 870 items in the search index, which is approximately the same amount of products we have in the Products list.

How to enable continuous crawls in Central Administration
You can only start a full crawl manually. Nobody wants the hassle of having to manually start a crawl every time a change is made to their catalog content, as this is neither an efficient nor practical way to work. So, to avoid this overhead, you can simply enable a continuous crawl of your content source that contains the catalog.
Continuous crawls start automatically at set intervals. Any changes that have been made to the catalog since the previous crawl, are picked up by the crawler and added to the search index.
To enable continuous crawls:
  1. Go to Central Administration --> Manage service applications --> Search Service Application --> Content Sources.
  2. On the Manage Content Sources page, click Your content source for which you want to enable continuous crawl, in our scenario case, this is Local SharePoint sites.
  3. Select the option Enable Continuous Crawls.

How to set continuous crawl interval
The default interval for continuous crawls is 15 minutes. You can set shorter intervals by using PowerShell. The code snippet below sets the continuous crawl interval to 1 minute.
$ssa = Get-SPEnterpriseSearchServiceApplication
$ssa.SetProperty("ContinuousCrawlInterval", 1)
So, by enabling continuous crawls, you can avoid a lot of frustration from content managers as they no longer have to wait for Search service application administrators to start a crawl for them. However, for some catalog changes, for example, enabling managed properties as refiners, continuous crawls are not sufficient, and you will need to do a full reindexing of the catalog content. But not to worry. Content managers have no reason for concern, because there is a way for them to initiate a full reindexing of the catalog.
How to initiate a reindexing of the catalog
To mark a catalog for reindexing, here's what to do:
  1. On your catalog (in our case the Products list in the Product Catalog Site Collection), click the LIST tab --> List Settings --> Advanced Settings.
  2. On the Advanced Settings page, click Reindex List.

How to view crawl status and schedule for a catalog
You can view the crawl status and schedule for an individual catalog. To do this:
  1. On your catalog (in our case the Products list in the Product Catalog Site Collection), click the LIST tab --> List Settings --> Catalog Settings.
  2. On the Catalog Settings page, you can see when the catalog was last crawled, and what crawls are scheduled to run when.
    In our case, we can see that the catalog was last crawled on 3/4/2013 at 5:30:17 AM, and that continuous crawls are scheduled to run every 15 minutes.

So, all in all, content managers can be happy because their content is added to the search index at short intervals, and Search service application administrators can be happy because they are no longer bothered by content managers constantly asking them to start a crawl.