Powershell script that will create a site

$Web = $ARGS[0]
$NewSiteName = $ARGS[1]
$SiteCollectionTemplate = "STS#0"
$SiteCollectionLanguage = "1033"
$PageLayout = "CHA_BlankWebPartPage.aspx"
$HomepageName = "home.aspx"
$SiteUrl = $Args[0] + "/" + $NewSiteName
#Create the new site
$SPWeb = Get-SPWeb -Identity $Web
New-SPWeb $SiteUrl -Template $SiteCollectionTemplate -Name $NewSiteName -UseParentTopNav -Language $SiteCollectionLanguage
$SPWeb = Get-SPWeb -Identity $SiteUrl
#Turn on Publishing features and create home.aspx in the Pages Library
Enable-SPFeature -Identity PublishingWeb -URL $SiteUrl
$pubWeb = [Microsoft.SharePoint.Publishing.PublishingWeb]::GetPublishingWeb($SPWeb)
$pl = $pubWeb.GetAvailablePageLayouts() | Where { $_.Name -eq $PageLayout }
$newPage = $pubWeb.AddPublishingPage($HomepageName,$pl)
$newPage.Update()

#Set the Homepage to Home.aspx
$rootfolder = $SPWeb.RootFolder
$rootFolder.WelcomePage = "Pages/Home.aspx"
$rootFolder.Update()
#Delete unneeded lists
$Guids = @()
foreach ($List in $SPWeb.lists){
 if($List.title -eq "Announcements"){$Guids += $List.id}
 if($List.title -eq "Tasks"){$Guids += $List.id}
 if($List.title -eq "Shared Documents"){$Guids += $List.id}
 if($List.title -eq "Site Assets"){$Guids += $List.id}
 if($List.title -eq "Site Pages"){$Guids += $List.id}
 if($List.title -eq "Team Discussion"){$Guids += $List.id}
}
foreach($element in $Guids){
 try{
  $SPWeb.Lists.Delete($element)
 }
 catch [Exception]{
  write-host "ERROR DELETING LIST: GUID"$element
  write-host "MESSAGE RETURN: "$_.Exception.Message
 }
}
#Add Webparts to the homepage
$ChromeType =[System.Web.UI.WebControls.WebParts.PartChromeType]::TitleOnly
$OpenWeb = Get-SPWeb $SiteUrl
$HomepagePath = "$SiteURL/pages/" + $HomepageName + "?PageView=Shared"
write-host $HomepagePath
$WebPartManager  = $OpenWeb.GetLimitedWebPartManager($HomepagePath, [System.Web.UI.WebControls.WebParts.PersonalizationScope]::Shared)

#CALENDAR
$List = "Calendar"
$Zone = "Footer"
$OpenList = $OpenWeb.Lists[$List]
$ListViewWebPart = New-Object Microsoft.SharePoint.WebPartPages.ListViewWebPart
$ListViewWebPart.Title = $List
$ListViewWebPart.ListName = ($OpenList.ID).ToString("B").ToUpper()
$ListViewWebPart.ViewGuid = ($OpenList.DefaultView.ID).ToString("B").ToUpper()
$ListViewWebPart.ZoneID = $Zone
$ListViewWebPart.ChromeType = $ChromeType
$WebPartManager.AddWebPart($ListViewWebPart,$Zone,$Index)
#LINKS
$List = "Links"
$Zone = "TopRightRow"
$OpenList = $OpenWeb.Lists[$List]
$ListViewWebPart = New-Object Microsoft.SharePoint.WebPartPages.XsltListViewWebPart
$ListViewWebPart.Title = $List
$ListViewWebPart.ListName = ($OpenList.ID).ToString("B").ToUpper()
$ListViewWebPart.ViewGuid = ($OpenList.DefaultView.ID).ToString("B").ToUpper()
$ListViewWebPart.ZoneID = $Zone
$ListViewWebPart.ChromeType = $ChromeType
$WebPartManager.AddWebPart($ListViewWebPart,$Zone,$Index)
#Documents
$List = "Documents"
$Zone = "TopLeftRow"
$OpenList = $OpenWeb.Lists[$List]
$ListViewWebPart = New-Object Microsoft.SharePoint.WebPartPages.XsltListViewWebPart
$ListViewWebPart.Title = $List
$ListViewWebPart.ListName = ($OpenList.ID).ToString("B").ToUpper()
$ListViewWebPart.ViewGuid = ($OpenList.DefaultView.ID).ToString("B").ToUpper()
$ListViewWebPart.ZoneID = $Zone
$ListViewWebPart.ChromeType = $ChromeType
$WebPartManager.AddWebPart($ListViewWebPart,$Zone,$Index)
#Check in the page
$newPage.CheckIn("")
$newPage.ListItem.File.Publish("")
$OpenWeb.Dispose()

Access denied on site collection

We had to reattach a site collection database to a web application.  After that we were getting access denied for everyone including site owners and site collection admins.  For some reason, we could still get into the Site Settings page  ["/_layouts/settings.aspx"]

The fix was to add rights to the superuser and superreader accounts to the database.

On one of the web front ends, in Powershell, I ran the following commands:

$w = get-spwebapplication -identity http://webapplication
$w.GrantAccessToProcessIdentity("Domain\superuser")
$w.GrantAccessToProcessIdentity("Domain\superreader")

I don't know if I needed both of those, but I did both of those and it fixed the issue.

SharePoint 2010 - Changing Managed Account Passwords

Blog Post that spells out the process really well:
http://www.toddklindt.com/blog/Lists/Posts/Post.aspx?ID=301


Copied for my own posterity:

Content crawl account (sp_content)

How to change it

This account is used by the search service to access the content it crawls. Since it isn’t a managed account we have to deal with it manually. We know it’s not a managed account because we didn’t pick it from a list, and we had to enter its password when we set it up. If you don’t have access at the domain level to change other account’s passwords, you can still change this one, as long as it can change its own password. On any domain machine hit Ctrl-Alt-Delete and click “Change a password…” When the change password box comes up, put domain\sp_search (or any of the other accounts we’re changing) in the account box and change the password. This is a pretty low profile account and can safely be changed during the work day.

Once the password is changed in AD we can change it in SharePoint. Go to Central Admin > Application Management > Manage Service Applications (/_admin/ServiceApplications.aspx). Click your Search Service App. For each of your Search service applications there is a Default Content Crawl account. It’s listed on the front of the Search Admin page. Click it to change its password (or identity). Put the new password in. If you have any Crawl Rules that define another account, you’ll need to go through this process again. Also, if you have multiple search service apps, and they use different default crawl accounts you’ll need to repeat the process.

How to check it

This one is pretty easy to check. After AD and SharePoint have both been updated, just kick off a full crawl. If the passwords aren’t correct or don’t match the crawl will end very quickly and you’ll get lots of top level errors.

User Profile Sync Account (sp_userprofile)

This account is used by the User Profile Sync Service to read the Active Directory changelog, read user information and optionally write user information back to Active Directory. Like the sp_search account above this one is pretty safe to do during the day.

How to change it

You may also have to use the Ctrl-Alt-Delete trick above to change the password for this account in AD. After the password is changed go to your User Profile Service App (UPA) and go to the Configure Synchronization Connections page. Choose the domain connection that uses sp_userprofile and click Edit. Type the new password twice and click Populate Containers. If the password works, your OUs will show up along with the ones you’re syncing will be checked. Click OK to save the new password.

How to check it

Go back into the User Profile Sync service application and manually start a profile sync. A full or incremental will work. If you want to watch the sync as it happens, fire up "C:\Program Files\Microsoft Office Servers\14.0\Synchronization Service\UIShell\miisclient.exe" on the machine where the User Profile Sync Service Instance (UPS) is running. That’ll give you more information than Central Admin. If they sync runs, the password change is good.

Managed Accounts (sp_farm, sp_webapp, sp_serviceapps, sp_search)

This section should be how every account in SharePoint 2010 is handled. There should be no need for this blog post at all because of the magic of managed accounts. This functionality is new to SharePoint 2010 and the idea is that you enter a username and password in one place, then pick it from a list everywhere in SharePoint where you need it. There is also the option for SharePoint to manage the passwords. Since the username and password only exist in one place, it’s easy to update. They’re halfway there in this version. You’ll notice the sp_content and sp_userprofile accounts are not managed accounts, so we still have to change them manually. We’re getting closer though, there is hope.

How to change it

To change a managed account password go to Central Admin > Security > Configure Managed Accounts (/_admin/MangedAccounts.aspx). Click the Edit icon next to the account whose password you want to change.

This brings up the next screen.

There are three options for changing the password. The first, “Generate New Password,” tells SharePoint to go ahead and make up a password, set it in AD and change SharePoint’s stored copy of the password to match it. I was curious how strong these passwords are. Using a script I had (link removed due to a request from the script’s author) I decrypted the password SharePoint generated. I was pleasantly surprised.

The password SharePoint generated is 35 characters long, with mixed case letters, numbers, symbols and I can’t be sure, but I think a couple of clicking sounds. As this script shows, should you ever need to discover that password, it’s possible. Be careful using this option with the sp_farm account. If you don’t have the script I have (and I can’t give it to you, sorry  ) you won’t be able to discover the sp_farm account’s password and you’ll need to know it for the next section.

Your second option, “Set account to new value,” is like the first option, except you need to come up with the password on your own. SharePoint will change the password in AD and in SharePoint. It should be noted that for option #1 or #2 to work, the service account must have permission to change its own password, which is the Active Directory default.

The third option, “Use existing password” is what you’d use if the password has already been changed in AD and you just need to update SharePoint.

On a side note, at the bottom of this page is a list of all the components in the farm that are using this account as a managed account. This gives you a quick list of things to check after you’ve change the password.

Change these service accounts one at a time. After you’ve changed one account monitor the Timer Job and make sure it succeeds on every member of the farm. Then check its functionality to make sure everything work. Once that’s done, move on to the next managed account.

How to check it

Check the services that use each managed account to see if the password change made its way through. If you want to be super positive, reboot all your boxes. The ensures all the processes are restarted and forced to log back in with the new password.

User Profile Sync Service account (sp_farm)

The farm account (sp_farm) is a managed account, and we changed its password in the previous step. However, the Farm account is used by the User Profile Sync Service (UPS), but not as a managed account. Because we had to manually enter the password when we started the UPS we’ll have to enter the new one there too.

How to change it

Go to Central Admin > System Settings > Manage Services on Server (/_admin/Server.aspx). This page lets you start and stop service instances on each machine in your farm. From the “Server” dropdown choose the server that the UPS is running on. Hopefully its state is “started.” Click “Stop” and let the UPS stop. After it has stopped, click start to start it back up. Hopefully you’re at the June 2011 CU(14.0.6106) or later. The UPS could be a bit of a bugger to get started in earlier builds. Use Spence’s guide to brush up on getting it started. The UPS must run as the Farm account, and you must supply that account when you start it back up. If you chose the “Generate a password” option in the previous step for the Farm account you might be in a bit of a pickle, since you don’t know what the password is. If you have access to the script I referenced above (still can’t give it to you, still sorry about that) you will be able to discover it. If not, you’ll need to change it to something you do know. After you’ve put the new Farm account password in let the UPS start. If everything goes well this will take a few minutes. You can use the MSDN ULS Log Viewer to watch the service instance start and watch for errors.

How to check it

The first check is to make sure the User Profile Sync Service does indeed start. If it does, that’s a good sign. If it does not, it might not necessarily be a password issue. Reference Spence’s post above for troubleshooting steps. After the UPS is started, do a profile sync to be absolutely sure the password change is working.

Install Account (sp_install)

This is the account that’s used to install SharePoint. This is an easy one, as SharePoint (2010, at least) doesn’t store its password anywhere.

How to change it

Log in as sp_install, hit Ctrl-Alt-Delete and Change Password. Type in your new password. Twice. Correctly.

How to check it

Log out, log back in as sp_install. 

Farm Passphrase

Not really an account, but I thought I’d include it just the same. This passphrase is created when the farm is created, and is needed when a SharePoint server is added to a farm.

How to change it

Since this isn’t an account, you don’t need to do anything in Active Directory. To change the farm passphrase, use the PowerShell cmdlet Set-SPPassphrase. Since PowerShell hates it when you enter passwords in plain text there a couple of hoops you have to jump through. Type “help set-sppassphrase –examples” to see how to use it.

How to check it

I don’t know of any way to check this other than adding a new machine to the farm.

Secure Store Password

Like the farm passphrase, this isn’t a user account, but it’s a password that’s used to encrypt settings

How to change it

Go to Central Admin > Application Management > Manage Service Applications (/_admin/ServiceApplications.aspx). Click your Secure Store Service App. Click “Generate New Key” in the ribbon.

Type the new password in twice and click ok. SharePoint will reencrypt the contents of the Secure Store database.

How to check it

I haven’t tested this one, but I assume if the password is not correct, the service application won’t display the targets. That’s how it acts when you attach a Secure Store database but haven’t put in the password yet.

Bonus! SQL Server Reporting Services

This isn’t a SharePoint account, but I like you guys, so I thought I’d include it anyway. The customer I was doing this with (no burritos were involved, I made all that up) also had SSRS running. In a weird twist, SSRS was NOT running in SharePoint integrated mode.

How to change it

The directions for changing the SSRS password were pretty simple. Simply rerun the SSRS config tool and put in the new password. I followed the instructions in this MSDN article.

How to check it

Hit the SSRS Reports URL. If it comes up, the password change worked.

Those of you that attempted to change passwords in SharePoint 2007 can appreciate how simple and straightforward this process is in SharePoint 2010. There’s still room for improvement, but it’s pretty solid. The process I used above worked the very first time for every account involved, and resulted in very little end user downtime. While changing all the service account passwords is a big deal, using these steps can make it a low impact, and low stress event.

tk

Edit: Removed references to a PowerShell script that decrypts passwords. I was asked by the script’s author not to publish it. 12/18/2011

Stop a mysite from being deleted

Found this helpful post and am reposting here for my own records:
http://blog.ray1.net/2011/08/stop-mysite-from-being-deleted.html

Issue:
The My Site of [USER] is scheduled for deletion.
The My Site of [USER] is scheduled for deletion in 3 days. As their manager you are now the temporary owner of their site. This temporary ownership gives you access to the site to copy any business-related information you might need. To access the site use this URL: http://mysites/personal/[USER]

Cause:

• User profile deleted
• User profile re-imported
• User profile has its Personal site property missing

There's a Timer Job that runs every hour called My Site Cleanup Job. This job among other things looks at dbo.Profile_DeletedUsers and My Sites that don't have a current user profile association.
When it finds a My Site without a user profile association it adds the site to the dbo.MySiteDeletionStatus table in the Profile DB.

Fix:

• Ensure the User Profile has the site associated with his account
The following query will give you profiles with a My Site.
SELECT PropertyVal, p.* FROM dbo.UserProfileValue v inner join dbo.UserProfile_Full p on p.RecordID=v.RecordID where PropertyID=22 and PropertyVal is not null
If the account isn't there you need to go to: Central Administration > Manage User Profiles and add the URL to the Personal site property.
• Delete the MySiteDeletionStatus record.
  This table has a NotificationStatus column with values 1-3 calculated based on the Created column.
  1 = 14 days til deletion email, 2 = 3 days til deletion and 3 = 1 day til deletion.
  This last step is the only crucial one.

BTW: This theoretically will leave the Db in an unsupported state, because we're not supposed to edit or even query SP DB's directly... so don't tell anyone and no one will know.