How do I - Fix SharePoint ULS Logs not being written?

From time to time, you will run into a situation where you're looking for ULS logs in their regular place i.e. %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\15\LOGS\ but there aren't any log files being written.  Most of the time, the problem is simply that an admin might have changed the logging location.
  1. Ensure you're checking the correct logging location.
  2. Navigate to Central Admin >>> Monitoring >>> Configure Diagnostic Logging
  3. Check the Path value.  You can copy the value and paste it into your Windows Explorer address bar for quick access to the logging location.
If the logging location is correct, but you're still not getting logs on the server, check the Trace service.
  1. Open the Service console from the server where the logs aren't being written.
  2. Scroll down and check that the "SharePoint Tracing Service" is running.
  3. If the service is running, you may want to restart it for good measure.
  4. Most likely it's NOT running though.  If it's not, start the service.
  5. If the service does not use Local System for the account, but instead uses a domain account, it's likely that the password might have changed recently.  Obtain the new password and reset the credentials for the service and then restart the service.
If that isn't the issue, there's sometimes some access issue with the logging location at the time the service started up.  You could try toggling the logging location path value.
  1. Navigate to Central Admin >>> Monitoring >>> Configure Diagnostic Logging
  2. Check the Path value.  Change it to a folder that does exist.
  3. Click OK.
  4. Navigate back to the "Configure Diagnostic Logging" page.
  5. Change the Path value back to %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\15\LOGS\ and click OK.
I'll continually add more steps as I uncover more reasons logging doesn't work in SharePoint. ;-)


How do I - Manually force SharePoint patches or CU installations to complete using PSConfig.exe

SharePoint patching has always been a sore subject.  The installation of Cumulative Updates can leave your environment in a non functional state which is why Microsoft always recommend that you only install CUs if you are absolutely sure that the CU actually fixes something that is broken within your environment.  As with all other installation recommendations, it's always recommended that patches and CUs follow a proper change management path of DEV >>> QA >>> PROD in order to ensure minimal impact to production systems.

My standing recommendation to all my clients is as follows:

  1. Do NOT install any CU until it's been in the wild for at least a month.  There has been many retractions and re-publishings of CUs over the course of history and unfortunately, Microsoft's track records with CU regressions is not stellar.  The last thing you need to to install a CU that breaks your production environment.  By waiting a month, any obvious issues with the CU would become known before you apply it to your environment.
  2. Install the target patch or CU into DEV first.  Let it simmer in this environment for 2 weeks.  Ensure that you have the ability to roll back the CU through VM snapshots.  Since most DEV environments are virtual these days, this isn't really a problem.  If ANY issue is reported by developers in the DEV environment, investigate it and do NOT proceed to step 3 until you're sure the problem was not caused by the CU.  If the CU is the cause of the problem, simply roll back to your previous snapshot. Be sure this policy is well published and communicated, especially within your developer community as developers would lose any code that resided on the DEV farm without being checked into source control, when you conduct the rollback.  But that never happens, right?  Developers always check their code into source control, right? ;-)
  3. Once the CU passed the DEV test, it's time to move it to your QA environment for validation against what should be in PROD.  Again, the assumption here is that your QA environment is a true representation of the PROD environment.  If the CU breaks anything in QA, simply stop the process and do NOT proceed to step 4.  As with step 2 above, if your QA environment is also virtual (most are these days) then you can simply roll it back as well when problems are encountered.  Leave the CU in the QA environment for at least 2 weeks to simmer before advancing to step 4.
  4. Finally deploy the CU to your PROD environment.  Since there is no uninstall for CUs, and given that a lot of PROD SQL Servers are still physical, once you get to this point, there's no going back.  If some regression issues are discovered after you've installed to PROD, you're at the mercy of Microsoft releasing a patch to resolve the issue.  It is best to open a support ticket as soon as possible to help them determine how widespread and serious the regression is. 
Now in each of the install steps above, you'll sometimes find that running PSConfig.exe or the Configuration Wizard after completing the CU/Patch installation, would fail or get stuck.  This leaves you in no man's land and has to be resolved in order to complete the installation/upgrade.


When this happens, you can manually run PSConfig to force the completion as follows:

  1. Run the SharePoint Management Shell as admin.  (Right click icon, Run as Administrator)
  2. There should be a path to BIN already defined in the management shell, but if you get a command not found error when you enter PSConfig, you could manually change directory to C:\Program Files\Common Files\Microsoft Shared\web server extensions\14\BIN
  3. Execute psconfig.exe -cmd upgrade -inplace b2b -force -cmd applicationcontent -install -cmd installfeatures

If PSConfig fails on step 9 or 10, proceed as follows:

  1. Edit C:\ProgramData\Microsoft\SharePoint\Config\GUID\cache.ini
  2. Reset value to 1
  3. From the SharePoint Management Shell, execute stsadm -o execadmsvcjobs
  4. From the SharePoint Management Shell, execute psconfig.exe -cmd upgrade -inplace b2b -wait -force
This should complete your update successfully.


It is said that you don't HAVE to run PSConfig in a single threaded fashion as stated above, but from personal experience, whenever I've had issues with CU installations, it was because PSConfig was run concurrently on multiple servers in the farm, but I'd recommend you let your own personal experience be the judge.


How do I - Update the SharePoint Search Service Application Default Content Access account credentials using Powershell

When corporate security policy require that account passwords be updated, the Default Content Access Account used for the Search Service Application needs to be manually updated as well.  If your Search Service is in a funky state, this might not be possible using the browser UI.  When this happens, you'll need to resort to Powershell to save the day using the following script:

$userid = "domain\search_account";
$password = "account_password";
$ssa = Get-SPEnterpriseSearchServiceApplication "Search Service Application";
$sac = New-Object Microsoft.Office.Server.Search.Administration.Content($ssa);
$sac.SetDefaultGatheringAccount($userid, (ConvertTo-SecureString $password -AsPlainText -force));


SharePoint PowerShell error - The local farm is not accessible - Cmdlets with FeatureDependencyId are not registered

When you're new to a SharePoint farm, you may try to open the SharePoint Management Shell expecting to work in PowerShell.  Even though your account may be a local administrator on the server as well as a member of the SharePoint Farm Administrators group in Central Admin, you may still receive this error message:

The local farm is not accessible. Cmdlets with FeatureDependencyId are not registered.

The issue is related to access to the configuration database for SharePoint.  What you need to do is grant access to the user in question, to the configuration database in SQL Server.  This can be done with the following two PowerShell commands:

$db = Get-SPDatabase | where {$_.Type -eq "Configuration Database"}
Add-SPShellAdmin "domain\username" -database $db

We begin by using the Get-SPDatabase cmdlet to get a reference to the SharePoint databases.  When you execute Get-SPDatabase by itself, it will provide you a listing of all SharePoint databases in the farm.  By filtering the type of database to only "Configuration Database" via the where clause, we are able to return on the configuration database in the farm.
Using the returned reference from this, we can use the Add-SPShellAdmin cmdlet to grant the user in question access to the configuration database.

Happy SharePointing!