Flush BLOB cache in SharePoint

To flush the BLOB cache from web application

  1. Open a SharePoint Management Shell or ISE
  2. Copy the following code and paste it into a text editor, such as Notepad
  3. $webApp = Get-SPWebApplication "<WebApplicationURL>"
    Write-Host "Flushed the BLOB cache for:" $webApp
  4. Replace <WebApplicationURL> with the URL of the Web application whose BLOB cache you want to clear.
  5. Save the file, and name it FlushBLOBCache.ps1.


To flush the BLOB cache from ALL web application

           $wa = get-spwebapplicaton
           foreach($wapp in $wa)
            Write-Host "Flushed the BLOB cache for:" $wapp

SharePoint 2013 Upgrade Process – Part 2

Continuing on the SharePoint 2013 upgrade process from previous post, we will see some considerations and commands while planning upgrading content databases to SP 2013.

When you have upgraded to SharePoint 2013 from SharePoint 2010 the sites are still in 2010 format. The sites themselves have to be updated as well.

Farm Administrators can run the command “Request-SPUgradeEvaluationSiteCollections”  This creates an evaluation site collections and renders all the content in a different site collection.

The below command shows how many days the evaluation site will be stick around for evaluation.


We can push the reminder to upgrade the site collection :  $weba.UpgradeReminderDelay = 5

In case if you does not want to upgrade a site collection you can disable the option to upgrade for site collections users from SP management shell.


Lets see some throttle settings at Site Collection level, which shows the ConcurrentUpgradeSessionLimit which on requirement we can either decrease or increase. If we have a small content upgrade it better to spike the limit up otherwise it will not be much help.


Throttle settings on content database upgrade



Lets see some more action while we initiate a site collection upgrade from SP management shell.



Coming to some options while running either the site collection upgrade or content database upgrade, we have options to “-Throttled” or “-Unthrottled” what unthrottling means it just upgrade everything  immediately as a priority and will not put in throttling queue.

We can get the upgrade session info status by running this command “get-spsiteupgradesessioninfo -contentdatabase wss_content -showinprogress” we have other options like “-showcompleted” and “-showfailed”

we can remove a site from upgrade if its already queued to upgrade with “remove-spsiteupgradesessioninfo -identity http://intranet/sites/it&#8221;

Upgrade-SPContentDatabase WSS_Content -NoB2BSiteUpgrade -UseSnapshot

 This example upgrades the existing WSS_Content content database schema only while using a snapshot of the database to retain read-only access to the content during the upgrade. No build-to-build upgrade actions are performed on any site collections. This operation does not change the CompatibilityLevel for existing site collections in this database.

We have seen some of the PowerShell help necessary for upgrading. But we need to plan and test the whole process from a staging farm before and look at the upgrade performance and plan the schedule. Once again this is purely from and SharePoint Admin perspective, later in another post we will look at other dev aspects which are key for smooth upgrade.

http://technet.microsoft.com/en-us/library/cc262483(v=office.15).aspx                                                  http://technet.microsoft.com/en-us/library/ff607813(v=office.15).aspx

SharePoint Content databases move from one farm to another – data refresh process across farms

            Today we will see how we can get all the content (including Site Collections and Content Databases) from one SharePoint Farm to another farm. This also including content from Project Server Databases.

          While we are planning to upgrade SharePoint 2010 to 2013, we need to replicate the upgrade process in staging farm  to be as close to production farm. The main goal here is to move all the current content and from production farm to a staging farm where both the SharePoint farms share a similar architecture in terms of servers, service applications and web applications.

Note: project server db refresh process will follow in next post 🙂

The High level Plan:

  1. Gather all the web applications and their content databases.
  2. Get all the content databases from TST/Stagning env. where you want to detach all the databaess.
  3. Detach all the databases from the farm using a simple command or script (check below)
  4. Once verified all the databases have been detatched and remove them from DB servers.
  5. Backup and restore databases from PROD db server to this staging farm.(make sure the db owner is changed to farm service account)
  6. Mount the databases restored from prod and set the necessary max and warning site count.
  7. Restore any custom databases which are being used for any third party tools or custom solutions from PRD to Stage farm
  8. Clear all the SharePoint Timer cache.
  9. Reset all the search index data for all the search applications and once attached all the databases fire a full search.
  10. If you have blog cache implemented then you need to refresh the cache (delete and let it rebuild again)
  11. Restore “emailenabledlists” table from sharepoint_config database (what ever is the config db in prod ) to stage (optional: this isonly required if you need the email enabled lists and email details of the lists/doc. libraries/discussion forums you want to restore)
The remaining challenges for the staging farm to be identical was to migrate the managed metadata database from prd farm and 
Now lets see the basic PowerShell cmdlets to be executed for the above steps:
Web application – site collections and content databases can be gathered: (execute for each web application)
PowerShell shell:>Get-spcontentdatabase  -webapplication http://webapplication | select name  > c:webapplicationname-contentdatabase.txt
Note: In case if we use more than one SQL DB instances, we need to make sure content databases are restored in respective DB instances as per the farm architecture.
UnMount Databases – Simple PowerShell script – copy all your databases we captured in the above step to one file:
$dblist = get-content c:stg-detatchdb.txt
foreach($db in $dblist)
      dismount-spcontentdatabase -identity $db -Confirm:$FALSE
Attached databases in Stg farm:
$dblist = get-content c:stg-attachdb.txt
foreach($db in $dblist)
Mount-SPContentDatabase -WebApplication http://webappname -Name $db -Confirm:$FALSE -DatabaseServer “dbsreverinstance” -MaxSiteCount -WarningSiteCount
# your can use the below command to again set the max and warning site count
#Set-SPContentDatabase -identity $db -Confirm:$FALSE -MaxSiteCount 1 -WarningSiteCount 0
You can clear the timer cache either manually on each server in the following way 
Either you can clear the cache using a simple script:
Add-PSSnapin Microsoft.SharePoint.PowerShell -erroraction SilentlyContinue
$servers = getspserver | ? { $_.Role eq “Application” }
$configDb = Get-SPDatabase | ? {$_.TypeName -eq “Configuration Database”}
$guid = $configDb.Id
foreach($spserv in $servers)
set-service -computername $spserv -Name sptimerv4 -status stopped
sleep 5
Remove-Item “\$spservc$ProgramDataMicrosoftSharePointConfig$guid*.xml”
Set-Content “\$spservc$ProgramDataMicrosoftSharePointConfig$guidcache.ini” “1”
sleep 5
set-service -computername $spserv -Name sptimerv4 -status Running
sleep 300

Add-PSSnapin Microsoft.SharePoint.PowerShell -erroraction SilentlyContinue
foreach($webApp in $WebAppServices)
     Write-Host $webApp
Remove-PsSnapin Microsoft.SharePoint.PowerShell
This completes the content db restore from one farm to another, I will write how to restore project server db refresh in next post.
Do write me back on your opinions and if we can improve on this process and include any missing pieces.

Reset SharePoint PassPhrase

Passphrase for SharePoint saves the farm from accidental addition of servers by known or unknown admins. One way its saves but if we does not document it somewhere or lost it then the only way to retreive it is to reset the passphrase

The passphrase resides some where in SharePoint Configuration database encrypted. We need to set a new passphrase using the cmdlet Set-SPPassPhrase. Before we need to pass the new passphrase we need to convert it to secure string.
Follow the steps:
Note: Run these cmdlets on a server which is still part of a server, if the server is disconnected already from the farm then it cannot connect to configuration database to update the passphrase.
Open a sharepoint Management (powershell) Shell

$Pass = ConvertTo-SecureString -AsPlainText -Force

It will prompt to enter the passphrase now
Set-SpPassPhrase -PassPhrase $Pass
It will ask you to reenter the passphrase you need to enter the passphrase you already gave it in earlier step.