Use the following PowerShell script to move a Site Collection to a different Content Database:

 Move-SPSite <http://ServerName/Sites/SiteName> -DestinationDatabase <DestinationContentDb> 

The following PowerShell allows you to write to a file a list of all the users in the Site Owners group of all sites in a site collection:

$txt = ""
$siteUrl = Read-Host "enter site url here:"

$rootSite = New-Object Microsoft.SharePoint.SPSite($siteUrl)

foreach($subsite in $rootSite.AllWebs) {
    foreach($siteAdmin in $subsite.SiteAdministrators) {
        #$txt += "$($siteAdmin.ParentWeb.Url);$($siteAdmin.DisplayName);Site Admin`r"
    }
	foreach($group in $subsite.Groups) {
		if ($group.Name.ToLower().Contains("owner")) {
			foreach ($owner in $group.Users) {
				$txt += "$($siteAdmin.ParentWeb.Url);$($owner.Name);Site Owner`r"
			}
		}
	}
    $subsite.Dispose()
}
$rootSite.Dispose()

out-file -filepath owners.csv -inputobject $txt

I got most of it from this question on StackOverflow

After applying the latest Windows updates for Windows Server 2003, we received many “Timed Out” errors when trying to run content deployment jobs.  The main culprit of there errors seemed to be the OWSTIMER.EXE process and it taking 100% of the CPU… yeah, I know “it’s a pain!”

Anyway, one of the things I did to try and get the issue resolved was to clear out the years of Content Deployment objects that had built up on the target server.

This was a 2 step process:

1. Find all the Content Deployment Job objects in the config database and get their IDs

   select * from Sharepoint_Config.dbo.[Objects]  where [Name] like 'ContentDeploymentJobDefinition%'

2. Run an stsadm command to delete the object based on its ID
   

   STSADM -o deleteconfigurationobject -id "<object id>"

I was able to do some text manipulating and get a really long .bat file that ran for a really long time. When it was done, all the Content Deployment Job objects were gone.

However, it did not seem to fix my issue with OWSTIMER.EXE taking 100% of the CPU.

The solution for that seemed to be narrowing down which Content Deployment Job was causing the issue by disabling them all and then re-enabling them one at a time and deleting the target site collection and doing a full deployment.

Todd Klindt has a great post (Using PowerShell to find site collection size in SharePoint 2010) that outlines how to find all the site collections in a SharePoint 2010 Web and report it’s size.  Below is the content of that post:

Today on Twitter I received a message from Nik Patel:

“How would I determine the site collection size using powershell? I am sure you have figured it out.. ”

As luck would have it, I had. The good news is that PowerShell exposes that information pretty easily. Even an admin like myself can figure it out. Let’s walk through how I put this all together. First I set a variable to a site collection so that I could take a look at the properties that were exposed.

$sc = get-spsite http://sharepoint

$sc | get-member

From here I saw the Usage property. That looks promising. executed $sc.usage did give me the storage used by a site collection, but it looked a bit more complicated:

PS C:\> $sc.Usage

Storage           : 9621220
Bandwidth         : 0
Visits            : 0
Hits              : 0
DiscussionStorage : 0

I only wanted the storage usage, so I needed a good way to pull all that out. Plus I needed it for all the site collections, not just one. That lead me to this line:

Get-SPSite | select url, @{label="Size in MB";Expression={$_.usage.storage}}

This gives me the information I wanted, but the presentation leaves a bit to be desired. This line worked a little better:

Get-SPSite | select url, @{label="Size in MB";Expression={$_.usage.storage/1MB}} | Sort-Object -Descending -Property "Size in MB" | Format-Table –AutoSize

This gave me the storage usage in megabytes instead of bytes, sorted the site collections by size, and formatted it all nicely. To go for the gold I decided to take it one step farther:

Get-SPSite | select url, @{label="Size in MB";Expression={$_.usage.storage/1MB}} | Sort-Object -Descending -Property "Size in MB" | ConvertTo-Html -title "Site Collections sort by size" | Set-Content sc.html

This takes the output from above and writes it to an HTML file for easier viewing.

You can view the entire transcript and the HTML output if you’d like.

Happy PowerShelling.

tk

Thanks, Todd!

There are several steps that you need to take in order to enable anonymous access.  Below are the steps taken from Microsoft TechNet.

Enable anonymous access for a zone of a Web application

1. From Administrative Tools, open the SharePoint Central Administration Web site application.

2. On the Central Administration home page, click Application Management.

3. On the Application Management page, in the Application Security section, click Authentication providers.

4. On the Authentication Providers page, make sure the Web application that is listed in the Web Application box (under Site Actions) is the one that you want to configure. If the listed Web application is not the one that you want to configure, click the drop-down arrow to the right of the Web Application drop-down list box and select Change Web Application.

5. In the Select Web Application dialog box, click the Web application that you want to configure.

6. On the Authentication Providers page, click the zone of the Web application on which you want to enable anonymous access. The zones that are configured for the selected Web application are listed on the Authentication Providers page.

7. On the Edit Authentication page, in the Anonymous Access section, select Enable Anonymous Access, and then click Save.

At this point, the Web application zone has been enabled for anonymous access.

Enable anonymous access for individual sites

Now you need to enable anonymous access for individual sites in the site collection.

Enable anonymous access for individual sites

1. Go to the site on which you want to enable anonymous access and click the Site Actions menu.

2. On the Site Actions menu, click Site Settings.

3. On the Site Settings page, in the Users and Permissions section, click Advanced Permissions.

4. On the Permissions page, on the Settings menu, click Anonymous Access. The settings for anonymous access lists three options:

   • Entire Web site   Select this option if you want to enable anonymous access for the entire Web site.

   • Lists and libraries   Select this option if you want to limit anonymous access to only the lists and libraries on your site.

   • Nothing   Select this option if you want to prevent anonymous access from being used on your site.

5. Click OK.

At this point, your site is configured for anonymous access based on the options that you have selected.

Enable anonymous access for individual lists

If you select Lists and libraries, enable anonymous access for individual lists.

Enable anonymous access for individual lists

1. Go to the home page of your Web site and, in the left navigation pane, click View All Site Content.

2. Click the list on which you want to enable anonymous access.

3. On the Settings menu, click List Settings.

4. On the Customize List page, in the Permissions and Management section, click Permissions for this list.

5. On the Permissions page, on the Actions menu, click Edit Permissions. A dialog box is displayed informing you that you are about to create unique permissions for this list. Click OK.

6. On the Settings menu, click Anonymous Access.

7. Select permissions for users who have anonymous access to the list, and then click OK.

At this point, users have anonymous access to the list you have configured. You can control whether users have anonymous access to other lists, the home page, or other pages on this site.

I used a tool by Steven Van de Craen called FaultyFeatureTool to compare the features that were enabled on two different sites.

It’s not the original purpose of this tool but it came in very handy.

You can also remove the feature using the application or STSADM.

[code lang="dos"]
STSADM -o deactivatefeature -id -url http://localhost -force
[/code]

When trying to enable the Office SharePoint Server Publishing Infrastructure feature we were getting an “Access Denied” error.  The error in the application event log was:

Event Type:    Error
Event Source:    Office SharePoint Server
Event Category:    Publishing Provisioning
Event ID:    4965
Date:        5/13/2009
Time:        10:16:31 AM
User:        N/A
Computer:    SERVERNAME
Description:
Event log message was: ‘Failed to provision the scheduling job definitions.  Page scheduling will not succeed.’. Exception was: ‘System.Security.SecurityException: Access denied.
…

To resolve the issue, we took the following steps:

1. Used stsadm to activate the feature:
   1. [code lang="dos"]stsadm -o activatefeature -name PublishingResources -url http://www.example.com[/code]
2. Clicked the [Activate] button on the Site Collection Features page.