We recently expanded our FAST for SharePoint 2010 farm to include a second failover location. As it had been nearly a year since we rolled out our primary farm it was a good chance to validate our deployment documentation and to validate we could quickly and easily build our farm from scratch. All went well until the end in which we were validating the deployment of the FAST instance. It was discovered that the configuration of our FAST servers was incorrect. Unfortunately, this was discovered after we had spent several days completing the crawl of all our content. What the mistake was to assign the Query role to the wrong row of servers. Fortunately, it was possible to reconfigure the FAST servers without resetting or re-crawling our content by modifying the deployment.xml and running the Set-FASTSearchConfiguration PowerShell command. 

Environment detail:

• Windows 2008 R2 SP1 (KB976932)

• SharePoint 2010 SP1 w/June 2011 CU

• FAST for SharePoint 2010 SP1 w/June CU

§ 5 Rows

§ 4 Columns

Server role changes:

1. Remove the first row from serving queries.
2. Add the abilty for the second row to perform indexing.

Steps to Reconfigure:

1. Synchronize the primary and the backup indexer servers

https://technet.microsoft.com/en-us/library/gg482028.aspx

2. Reconfigure the farm deployment without adding new server.

https://technet.microsoft.com/en-us/library/ff381247.aspx#BKMK_ReconfigureTheDeploymentWithoutAddingNewServers

Problem:

I recently setup a new SharePoint environment to host a single site collection. Even though there was not a lot of content on this small farm, the environment needed to be highly available and we needed the ability to lose no more than one hour worth of data in the case of a catastrophic failure. Retaining backups for one week was plenty for our needs. Users of the site were located globally making the site's least utilized time in the evenings (PST) with the biggest window on Saturday.

Based on this and the idea of keeping the process easy and lightweight as possible (i.e. out-of-the-SharePoint-box and running from a single location) I decided to go this route:

1. Full farm backup on Saturday afternoon
2. Differential farm backup on Sunday-Friday evenings
3. Hourly differential backups on content databases
4. Clean out last weeks Full and Differential backups on early Monday morning

Problem was I didn't know how I was going to accomplish this and than fully automate it. Breaking down this problem I determined I had three steps to make this work:

1. Run backups via PowerShell
2. Run these PowerShell scripts from Task Scheduler
3. Cleanup backups

Solution:

1. Run backups via PowerShell
   • Using the TechNet documentation for reference I used the following one-liner for Full and Differential farm backup:
             Backup-SPFarm -Directory <backupFolder> -BackupMethod {Full | Differential} [-Verbose]
     
     
   • This is what I used for the hourly content db backups:
             Backup-SPFarm -Directory <backupFolder> -BackupMethod Differential -Item <contentDBName>
     
     
   • I took these commands and placed them into individual .ps1 files (FullFarmBackup.ps1, DiffFarmBackup.ps1 and HourlyContentDBBackup.ps1) and put them into E:\backupScripts.
     
     
2. Run these PowerShell backups from Task Scheduler
       Getting Task Scheduler to run a PowerShell script with the SharePoint snap-in was a lesson in trial and error. Ultimately this is what I did to get it working.
   • In all my .ps1 scripts I need to have the SharePoint snap-in loaded. To do this I added the live "Add-PSSnapin Microsoft.SharePoint.PowerShell" at the top.
     
         Add-PSSnapin Microsoft.SharePoint.PowerShell
         Backup-SPFarm -Directory <backupFolder> -BackupMethod {Full | Differential} [-Verbose]
     
   • Under the Action tab of the task I created:
     • Program/Script = powershell
     • Add Argument (optional) = E:\backupScripts\FullFarmBackup.ps1
       
       
       
       
3. Automate the cleanup of the above backups
      
   Because I didn't have infinite disk space and didn't need backups greater than 1 week I needed a means to cleanup old backups. Running a quick Bing search I ran across a blog post on 'Imperfect IT' that did just this. Here is a copy of what was posted on that site and to which I placed into Task Scheduler:
   
       # Location of spbrtoc.xml
       $spbrtoc = "<backupFolder>"
   
       # Days of backup that will be remaining after backup cleanup.
       $days = 7
   
       # Import the Sharepoint backup report xml file
       [xml]$sp = gc $spbrtoc
   
       # Find the old backups in spbrtoc.xml
       $old = $sp.SPBackupRestoreHistory.SPHistoryObject |
       ? { $_.SPStartTime -lt ((get-date).adddays(-$days)) }
       if ($old -eq $Null) { write-host "No reports of backups older than $days days found in spbrtoc.xml.'nspbrtoc.xml isn't changed and no files are removed.'n" ; break}
   
       # Delete the old backups from the Sharepoint backup report xml file
       $old | % { $sp.SPBackupRestoreHistory.RemoveChild($_) }
   
       # Delete the physical folders in which the old backups were located
       $old | % { Remove-Item $_.SPBackupDirectory -Recurse }
   
       # Save the new Sharepoint backup report xml file
       $sp.Save($spbrtoc)
       Write-host "Backup(s) entries older than $days days are removed from spbrtoc.xml and harddisc."
   

I now have 4 scheduled tasks running (Full farm, Diff farm, Hourly content db and cleanup) that provide me the ability to fulfill our simple backup strategy.

Problem:
    "No Access Database Service is available in the farm."

Cause:
    Asset Library Web Database uses the Access Database Service which was not running by default.

Resolution:
    1. Go to Central Administration Page
    2. Select Application Management
    3. Under Service Applications select ‘Manage services on server’
    4. First item listed is Access Database Service – start this service