#-----------------------------------------------------------------------------
# Name: Move-SPEnterpriseSearchIndex.ps1
# Description: This script will move the SharePoint 2013 Search Index
#
# Usage: Run the function with the 3 required Parameters
# By: Ivan Josipovic, Softlanding.ca
#-----------------------------------------------------------------------------
function Move-SPEnterpriseSearchIndex($SearchServiceName,$Server,$IndexLocation){
Add-PSSnapin Microsoft.SharePoint.PowerShell -ea 0;
#Gets the Search Service Application
$SSA = Get-SPServiceApplication -Name $SearchServiceName;
if (!$?){throw "Cant find a Search Service Application: `"$SearchServiceName`"";}
#Gets the Search Service Instance on the Specified Server
$Instance = Get-SPEnterpriseSearchServiceInstance -Identity $Server;
if (!$?){throw "Cant find a Search Service Instance on Server: `"$Server`"";}
#Gets the current Search Topology
$Current = Get-SPEnterpriseSearchTopology -SearchApplication $SSA -Active;
if (!$?){throw "There is no Active Topology, you can try removing the `"-Active`" from the line above in the script";}
#Creates a Copy of the current Search Topology
$Clone = New-SPEnterpriseSearchTopology -Clone -SearchApplication $SSA -SearchTopology $Current;
#Adds a new Index Component with the new Index Location
New-SPEnterpriseSearchIndexComponent -SearchTopology $Clone -IndexPartition 0 -SearchServiceInstance $Instance -RootDirectory $IndexLocation | Out-Null;
if (!$?){throw "Make sure that Index Location `"$IndexLocation`" exists on Server: `"$Server`"";}
#Sets our new Search Topology as Active
Set-SPEnterpriseSearchTopology -Identity $Clone;
#Removes the old Search Topology
Remove-SPEnterpriseSearchTopology -Identity $Current -Confirm:$false;
#Now we need to remove the extra Index Component
#Gets the Search Topology
$Current = Get-SPEnterpriseSearchTopology -SearchApplication $SSA -Active;
#Creates a copy of the current Search Topology
$Clone=New-SPEnterpriseSearchTopology -Clone -SearchApplication $SSA -SearchTopology $Current;
#Removes the old Index Component from the Search Topology
Get-SPEnterpriseSearchComponent -SearchTopology $Clone | ? {($_.GetType().Name -eq "IndexComponent") -and ($_.ServerName -eq $($Instance.Server.Address)) -and ($_.RootDirectory -ne $IndexLocation)} | Remove-SPEnterpriseSearchComponent -SearchTopology $Clone -Confirm:$false;
#Sets our new Search Topology as Active
Set-SPEnterpriseSearchTopology -Identity $Clone;
#Removes the old Search Topology
Remove-SPEnterpriseSearchTopology -Identity $Current -Confirm:$False;
Write-Host "The Index has been moved to $IndexLocation on $Server"
Write-Host "This will not remove the data from the old index location. You will have to do that manually :)"
}
Tuesday, 3 February 2015
Moving SharePoint 2013 Search index location
I found this script at https://gallery.technet.microsoft.com/office/Move-SharePoint-2013-242869e2
Comments indicate the Author. I have it on my blog so I can find it when I need it :D NOTE: This will not work on stand alone installations
Sunday, 1 February 2015
SharePoint 2013 crawl index reset hanging / timming out
This morning I tried to reset the search crawl index and found it timmed out. In the uls the following error was reported.
Thanks to another blog:
http://www.social-point.com/sharepoint-2010-event-id-6482-application-server-administration-job-failed-for-service-instance-microsoft-office-server-search-administration-searchserviceinstance
I was able to resolve it.
Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance (21e4447f-bac6-4a29-82db-165e074ac5db). Reason: An update conflict has occurred, and you must re-try this action. The object SearchDataAccessServiceInstance was updated by domain\user, in the OWSTIMER (5040) process, on machine (server name). View the tracing log for more information about the conflict. Technical Support Details: Microsoft.SharePoint.Administration.SPUpdatedConcurrencyException: An update conflict has occurred, and you must re-try this action. The object SearchDataAccessServiceInstance was updated by domain\user, in the OWSTIMER (5040) process, on machine (server name). View the tracing log for more information about the conflict. at Microsoft.Office.Server.Search.Administration.SearchServiceInstance.Synchronize() at Microsoft.Office.Server.Administration.ApplicationServerJob.ProvisionLocalSharedServiceInstances(Boolean isAdministrationServiceJob) - See more at: http://www.social-point.com/sharepoint-2010-event-id-6482-application-server-administration-job-failed-for-service-instance-microsoft-office-server-search-administration-searchserviceinstance#sthash.C89dth4G.dpuf
The following procedure needs to be run on all WFE's in your farm
Make sure that the Cache.ini file in the GUID folder now contains its previous value. For example, make sure that the value of the Cache.ini file is not 1.
Thanks to another blog:
http://www.social-point.com/sharepoint-2010-event-id-6482-application-server-administration-job-failed-for-service-instance-microsoft-office-server-search-administration-searchserviceinstance
I was able to resolve it.
Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance (21e4447f-bac6-4a29-82db-165e074ac5db). Reason: An update conflict has occurred, and you must re-try this action. The object SearchDataAccessServiceInstance was updated by domain\user, in the OWSTIMER (5040) process, on machine (server name). View the tracing log for more information about the conflict. Technical Support Details: Microsoft.SharePoint.Administration.SPUpdatedConcurrencyException: An update conflict has occurred, and you must re-try this action. The object SearchDataAccessServiceInstance was updated by domain\user, in the OWSTIMER (5040) process, on machine (server name). View the tracing log for more information about the conflict. at Microsoft.Office.Server.Search.Administration.SearchServiceInstance.Synchronize() at Microsoft.Office.Server.Administration.ApplicationServerJob.ProvisionLocalSharedServiceInstances(Boolean isAdministrationServiceJob) - See more at: http://www.social-point.com/sharepoint-2010-event-id-6482-application-server-administration-job-failed-for-service-instance-microsoft-office-server-search-administration-searchserviceinstance#sthash.C89dth4G.dpuf
The following procedure needs to be run on all WFE's in your farm
- stop the Windows SharePoint Services Timer service (Found in Windows Services)
- Navigate to the cache folder In Windows Server 2008, the configuration cache is in the following location:
Drive:\ProgramData\Microsoft\SharePoint\Config
In Windows Server 2003, the configuration cache is in the following location:
Drive:\Documents and Settings\All Users\Application Data\Microsoft\SharePoint\Config - Locate the folder that has the file "Cache.ini" (Note: The Application Data folder may be hidden. To view the hidden folder, change the folder options as required)
- Back up the Cache.ini file
- Delete all the XML configuration files in the GUID folder. Do this so that you can verify that the GUID folder is replaced by new XML configuration files when the cache is rebuilt. Note When you empty the configuration cache in the GUID folder, make sure that you do not delete the GUID folder and the Cache.ini file that is located in the GUID folder.
- Double-click the Cache.ini file.
- On the Edit menu, click Select All. On the Edit menu, click Delete. Type 1, and then click Save on the File menu. On the File menu, click Exit.
- Start the Windows SharePoint Services Timer service
Make sure that the Cache.ini file in the GUID folder now contains its previous value. For example, make sure that the value of the Cache.ini file is not 1.
Subscribe to:
Comments (Atom)