Retaining the Search Scope of Search Area Dropdown value during the postbacks in SharePoint

During the implementation one of my colleague faced the issue of losing the value of search scope during the postbacks, below are the two steps to include to all MasterPages

Step  I :

Create the attribute dynamically as below at delay loading include it to very end,

<script language=”javascript”>

//Set the attribute dynamically to Searchbox Area control

var e = document.getElementById(“ctl00_PlaceHolderSearchArea_ctl00_SBScopesDDL”);

var strSelectedSearchScope = e.options[e.selectedIndex].text;

var att=document.createAttribute(“onchange”);



// Retain the value of the Dropdown during the postbacks



Step  II :

Write the below function as early loading include it to very beginning,

function SetSearchScopeValue()


var c_DropDownIndex=”DropDownIndex”;

var e =  document.getElementById(“ctl00_PlaceHolderSearchArea_ctl00_SBScopesDDL”);

var c_DropDownIndexValue=e.options[e.selectedIndex].text;

document.cookie=c_DropDownIndex + “=” + c_DropDownIndexValue;


function ReSetSearchScopeValue()


var c_DropDownIndex= “DropDownIndex”;

var v_DropDownIndex=getCookie(c_DropDownIndex);

var dd = document.getElementById(“ctl00_PlaceHolderSearchArea_ctl00_SBScopesDDL”);


for (var i = 0; i < dd.options.length; i++)


if (dd.options[i].text == v_DropDownIndex)


dd.selectedIndex = i;





function getCookie(c_name)


var c_value = document.cookie;

var c_start = c_value.indexOf(” ” + c_name + “=”);

if (c_start == -1)


c_start = c_value.indexOf(c_name + “=”);


if (c_start == -1)


c_value = null;




c_start = c_value.indexOf(“=”, c_start) + 1;

var c_end = c_value.indexOf(“;”, c_start);

if (c_end == -1)


c_end = c_value.length;


c_value = unescape(c_value.substring(c_start,c_end));


return c_value;



Understanding of Backup and Restore Thread Count SharePoint Administrator

Concept of Threading in Hardware and Software:

Scalability in the hardware and software space is all about parallel computing nowadays. Consider our modern hardware: it used to be that all we really cared about was how fast our CPU could run (“how many GHz?”) Now, we care more about how many cores our CPU has, whether or not those cores support Hyper-threading, how many memory channels our CPU has available to it, etc. Scale-out beats scale-up.

The same is largely true in the software space. Most IT folks learned some time ago that “multithreading” and “higher performance” tended to go hand-in-hand or were at least associated in some way. Multiple threads of execution meant better scheduling of limited processor resources and fewer chances that one long-running operation would bottleneck an entire application.

Configuring SharePoint 2010 Farm Backup and Restore

When I first saw the following section in the “Configure Backup Settings” section of SharePoint 2010’s Central Administration site, it brought a big grin to my face:

Thread Configuration

In SharePoint 2007 and earlier, administrators had no real levers to pull to try and tune the performance of farm backup and restore operations. This obviously changed with SharePoint 2010. We were basically being handed a way to adjust those processes as we saw fit – for better or worse.

Strangely enough, though, I never really took the time to explore the impact of those settings in my SharePoint environments. I always left the number of assigned threads for backup and restore operations at three. I would have liked to mess around with the values, but something else was always more important in the grand scheme of things.

How Backup and Restore Thread Count improve performance?

According to Microsoft TechNet post titled Backup and recovery best practices (SharePoint Server 2010)

If you are using the Backup-SPFarm cmdlet, you can use the BackupThreadsparameter to specify how many threads SharePoint Server 2010 will use during the backup process. The more threads you specify, the more resources that backup operation will take, but the faster that it will finish, if sufficient resources are available. However, each thread is reported individually in the log files, so using fewer threads makes interpreting the log files easier. By default, three threads are used. The maximum number of threads available is 10.

Without an understanding of how multithreading (in general) and SharePoint backup (specifically) work, this could easily be interpreted as follows:

The greater the number of threads you assign, the faster your backups will complete.


Setting the number of backup threads to 10 on a SharePoint Server of infinite capability and resources doesn’t guarantee a fast backup, because the farm might have a slow SQL Server, a less-capable backup destination location, a slow or congested network, or a host of other complicating factors.

The number of threads that should be used during the backup. For Windows SharePoint Services, the recommended value is 3 threads.

The default value is 1. The fewer the threads, the easier it is to read and understand the backup log file.