The sites and site collections of your intranet, extranet, and publishing portals make up the foundational structure for your users. A SharePoint farm can grow quickly once the site collections are turned over to their owners. If you’re a sysadmin who wants to better understand how administering SharePoint 2013 with PowerShell can be used to help you manage your site collections (called “Sites” within the management shell), this article is going to help you get it all figured out.
Working with SharePoint 2013 Site Collections (SPSite) Using PowerShell
Most of the site collection administration is done with the SPSite cmdlets. Here are the basics of working with site collections in SharePoint 2013 through PowerShell.
Creating a New Site Collection with PowerShell
Use the New-SPSite cmdlet to create a site collection. Though there are several parameters for customizing just what you want, the only required information is the address of the site collection and who owns it. Use the –URL and –OwnerAlias parameters to create a site collection at any managed path.
Creating a Host Header Site Collection with PowerShell
If you’re creating a host header site collection, SharePoint won’t be able to identify the web application and managed path based on your URL, so use the –HostHeaderWebApplication parameter to tell SharePoint what web application the site collection is to be a part of.
Use Get-SPSite to find a site collection in SharePoint 2013. There are several different parameter sets, which means that sometimes a parameter identifies a specific way that you’re trying to use the command. For example, you can’t find a site collection by its content database and by its web application at the same time. It wouldn’t make sense to Get-SPSite. You can use either the parameter set that includes searching for a site by its content database, or you can search for a site collection by its web application.
Option 1: Find a site collection by its URL
This is the simplest usage of the Get-SPSite. Just add a URL and it will return the site collection. You’re actually adding it to the –Identity parameter, but if you only add in a single URL, then Get-SPSite knows what you are looking for.
Get-SPSite “http://hrweb.sharepoint.local”
Tip: If you want to use regular expressions then use the –Regex switch like: Get-SPSite “http://hr.*” -Regex
Option 2: Find a site collection by its web application
Get-SPSite –webapplication “http://my.sharepoint.local” –Limit All
Note: The Limit parameter is set by default to 200. You can specify more or less, or you can use “all” to not use any limits. Be sure to use an assignment collection (I’ll show this in the next section) if you’re going to return a lot of site collections and save them into a variable.
Option 3: Find a site collection by its content database
You can find the site collections that are using a content database by using the –ContentDatabase parameter on Get-SPSite, or by passing in the content database to the Get-SPSite through the pipeline.
By using the –Filter parameter, you can specify a scriptblock that can return only site collections that have values of properties that you specify. For example, if you only want to find site collections that are in maintenance mode, or site collections that require an upgrade.
How to Save a SharePoint 2013 Site Collection as a Variable
Assignment collections don’t have to be overly complicated. There’s a simple rule: If you’re saving a SPWeb or SPSite into a variable and taking operations on it, then there is a chance that large amounts of memory will be consumed. Use the assignment collection to identify memory management (think of it like a trash bucket), and then empty the trash bucket often.
Administering Sharepoint 2013 Site Collections with PowerShell
Now that you’ve gotten your site collections saved into a variable or ready to send through the pipeline, here’s what you can do with them.
Note: I find it easier to read and understand PowerShell code that uses a Get-SPSite command to find the site collections, then pipes them into the administrative cmdlet. This is a preference, not a requirement. You can specify the site collection to use in these commands by using the –Identity parameter.
Find Additional URLs for a Host Header Site Collection
If you have a host header site collection, it could have up to five URLs bound to it just like a SharePoint web application can have.
The five zones you can add a URL to are “Default, Internet, Intranet, Extranet, and Custom.”
Setting Settings on an SPSite
Modifying settings on a site collection is done with the Set-SPSite command. There are a lot of settings for a SPSite, and many can be set with this command. I’ll show you the usage and a few of the things you’re sure to find useful.
Use the –MaxSize of the Set-Site command to set the quota manually. You can also use the –WarningSize parameter to set an alarm for you when their approaching capacity. Specify the sizes in MB.
Similarly, you can make a site completely inaccessible with –LockState NoAccess, or allow for updates and deletions of existing content but prohibit new content with –LockState NoAdditions. When you’re ready for users to have full access again, use –LockState Unlock to restore full read/write functionality.
However, it’s likely that you’ll actually want to move the location of a SharePoint 2013 site collection from one location to another. For that, you can use the –URL parameter of the Set-SPSite cmdlet.
Note: If you’re using SQL Server Enterprise Edition you can use the –UseSQLSnapshot parameter to keep the site Read-Write during the backup process. Without that parameter, sites will be in read-only mode while they are backed up.
Restoring a Site Collection
You can restore a site collection to either the same URL or a different URL. You need to specify the path of the site collection backup, and where to restore the site collection to. You will use some of the same parameters you use to create new site collections, including specifying an existing content database to use or creating a new one.
Obviously, each of these commands could get a lot deeper coverage, but this should get you up and running with an awesome overview of what you can do with PowerShell when it comes time to administer your sites. As you get familiar with the techniques, you’ll quickly see that there’s really no comparison between the GUI and PowerShell when you have to manage site collections at a larger scale.
Routine management can sometimes be done more quickly using the GUI, especially if you’re not familiar with PowerShell and you only have to work on a small number of site collections. But when you have to find maybe hundreds of site collections and modify them all, you just can’t beat scripting with PowerShell for its effectiveness and efficiency.
Did I miss something? Did I get something wrong (or right)? Tell me about it in the comments below, or come find me on Twitter, Facebook, or my personal blog.