Iterate Through All Site Collections Within a Web Application to Change The Site Collection Administrator

If you have many Site Collections in a single web application and you want to set or change the Primary or Secondary Site Collection Administrator without going through each and every one in Central Administration, below is the script you can save as a .ps1 file and run in Powershell.  This script uses (-SecondaryOwnerAlias) to set the Secondary Site Collection Administrator. Change it to (-OwnerAlias) at line 19 to set the primary site collection admin.

## Input Parameters ##
[CmdletBinding()]
Param(
[string]$WebAppUrl=(Read-Host "Please enter a Web Application URL (Example: http://intranet)"),
[string]$Account=(Read-Host "Please enter an account (Example: DOMAIN\Administrator)")
)
## Add SharePoint Snap-in ##
Add-PSSnapin Microsoft.SharePoint.PowerShell -erroraction SilentlyContinue
### No need to modify these ###
$WebApp = Get-SPWebApplication $WebAppUrl
$AllSites = $WebApp | Get-SPSite -Limit ALL

##The Script - no need to modify this section ##
## Start SP Assignment for proper disposal of variables and objects ##
Write-Host "Starting SP Assignment..." -ForegroundColor Green
Start-SPAssignment -Global
## Use a ForEach-Object loop and Set-SPSiteAdministration to set an entire web application ##
Write-Host "Adding $Account to $WebAppUrl as a Site Collection Administrator..." -ForegroundColor Yellow
$AllSites | ForEach-Object { Set-SPSite -SecondaryOwnerAlias $Account -Identity $_.url }
## End SP Assignment for proper disposal of variables and objects ##
Write-Host "Disposing of SP Objects.." -ForegroundColor Green
Stop-SPAssignment -Global
## Tell us it's done ##
Write-Host "Finished!" -ForegroundColor Green

How To Set SharePoint Managed Service Account Password with PowerShell

Here is the scenario where this would be important:

Issue Cause
-       During the course of regular SharePoint administration duties a deployment process was hung up.  From past experience and part of the standard procedures in such situation, a SharePoint 2010 timer service was restarted and a command was run to force deployment of pending jobs.
-       When the jobs were forced to run, several pending jobs that were not scheduled to run were inadvertently triggered. The job that caused the issues was the automatic password change on SharePoint 2010 managed accounts. This job is typically scheduled for the 7th of every month, but is queued and marked as pending.  As the password change job was queued as pending the force command kicked off the password changes.  These jobs did not successfully complete and while the passwords were generated and updated in Active Directory, SharePoint was not updated.
-       This resulted in a password mismatch between the password in Active Directory and the password that the Web and Service Application Identities were using to run the sites. Furthermore, once the cached credentials on the IIS servers were refreshed the applications were no longer available.

Issue Resolution
Once the source of the problem was identified Admins needed to manually change the passwords on the affected accounts and then update the passwords in SharePoint.  Since CA was not accessible, passwords needed to be changed with PowerShell:

$P7 = ConvertTo-SecureString "password" -asplaintext -force

Set-SPManagedAccount -Identity <account name> -ExistingPassword $P7