SharePoint 2016 and dealing with Gatherer logs in the wrong place

Hello All,

Recently had to work with my customer to resolve an issue where the C: drive was filling up with logs, we started off with him sending me this screenshot that shows log files are in the C:\..\gthrsvc folder.

 

 

 

 

 

My customer was concerned that the index was being stored on the C: drive so first I had him run the following script which showed that the index was actually being stored on the E: drive as it was supposed to be

 #This Sample Code is provided for the purpose of illustration only and is not intended to be used in a production environment.  
#THIS SAMPLE CODE AND ANY RELATED INFORMATION ARE PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED 
#TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS for A PARTICULAR PURPOSE.  We grant You a nonexclusive, royalty-free right to use and modify 
#the Sample Code and to reproduce and distribute the object code form of the Sample Code, provided that You agree: (i) to not use Our name, logo, or 
#trademarks to market Your software product in which the Sample Code is embedded; (ii) to include a valid copyright notice on Your software product in 
#which the Sample Code is embedded; and (iii) to indemnify, hold harmless, and defend Us and Our suppliers from and against any claims or lawsuits,  

Add-PSSnapin Microsoft.SharePoint.PowerShell -ea SilentlyContinue

$ssa = Get-SPEnterpriseSearchServiceApplication
$Topo = Get-SPEnterpriseSearchTopology -SearchApplication $ssa -active
Get-SPEnterpriseSearchComponent -SearchTopology $Topo 

Then keying on the folder name, and assuming that it was connected to Gatherer service I stumbled across this blog with a comment from an awesome co-worker Anthony Casillas, based on that I then wrote this script

 #This Sample Code is provided for the purpose of illustration only and is not intended to be used in a production environment.  
#THIS SAMPLE CODE AND ANY RELATED INFORMATION ARE PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED 
#TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS for A PARTICULAR PURPOSE.  We grant You a nonexclusive, royalty-free right to use and modify 
#the Sample Code and to reproduce and distribute the object code form of the Sample Code, provided that You agree: (i) to not use Our name, logo, or 
#trademarks to market Your software product in which the Sample Code is embedded; (ii) to include a valid copyright notice on Your software product in 
#which the Sample Code is embedded; and (iii) to indemnify, hold harmless, and defend Us and Our suppliers from and against any claims or lawsuits,  

$NewTempPath = "D:\SearchTemp"
New-Item -Path $NewTempPath -ItemType Directory -ErrorAction SilentlyContinue

$GMPath = "HKLM:\SOFTWARE\Microsoft\Office Server\16.0\Search\Global\Gathering Manager"
Get-ItemPropertyValue -Path $GMPath -Name DefaultApplicationsPath
Set-ItemProperty -Path $GMPath -name DefaultApplicationsPath -Value $NewTempPath

Get-ChildItem -Path "HKLM:\SOFTWARE\Microsoft\Office Server\16.0\Search\Components" | ForEach-Object {
    $RegPath = ($_.Name).Replace("HKEY_LOCAL_MACHINE","HKLM:")
    Get-ItemPropertyValue -Path $RegPath -name LocalStoragePath
    Set-ItemProperty -Path $RegKey -name LocalStoragePath -Value $NewTempPath
}
Restart-Service OSearch16 

Things to know:

  1. This is supported for SharePoint 2016 installations
  2. There will be a short service interruption at the end when OSearch16 is restarted
  3. You should run this on all Search servers
  4. Modify the variable $NewTempPath to work for your enterprise

You can download the script from here

After restarting the service the log files were created in the new folder and we deleted the old files.

Pax