Quick SharePoint farm overview using PowerShell

Getting a quick overview of where your data is can be handy at times. Even to create reports. Using built-in SharePoint tools you can easily get site collection information from your whole farm, and convert that information to a CSV. Once you got that CSV, you can do anything with it.

The following script will export the selected data to a CSV file, called “Export.csv”. It will do this for all of the site collections, besides the central administration, in your farm.

Get-SPSite -limit all | select Url,Owner,@{label="ContentDatabase";Expression={$_.ContentDatabase.Name}},@{label="Size in MB";Expression={$_.Usage.Storage/1MB}} | Export-CSV -Path Export.csv -NoTypeInformation

When you open the CSV, you’ll get an output like this:

"Url","Owner","ContentDatabase","Size in MB"
"http://sharepoint","fondant\administrator","SHP2013_Content_SharePoint80","1.93870639801025"
"http://sharepoint/sites/apps","fondant\administrator","SHP2013_Content_SharePoint80","1.1555118560791"
"http://sharepoint/sites/team","fondant\administrator","SHP2013_Content_SharePoint80","1.85408592224121"
"http://sharepoint:81","fondant\administrator","SP2013_Content_SharePoint81","0.111626625061035"

Now you can do practically anything with the data. If you want more properties, check out the SPSite object, and add these to the select statement.

Copy site collection from source farm to target farm

Copying content allows the replication of production data in another environment. The result will be identical environments, which provides the ideal testing environment.

Prerequisites

In order to successfully restore your data, make sure you fulfil the following requirements:

1. Your account is in the local admin group of the production environment
2. Your account is in the local admin group of the target environment
3. The production environment should have the same or a lesser patch version than the target environment.
4. Both environments should have the same solutions deployed for the source and target web applications.
5. Your target site collection should not exist to avoid conflicts.

Database restore

Ask the SQL team nicely to restore a copy of the production content database of your source web application where the site collection resides, to the target SQL instance.

Note: Make sure the dbo of the target database is the web application service account of your target farm.

When the target database is restored, it’s time to bring it into SharePoint. Here a first decision has to be made:

• Is the source managed path different from the target managed path? For example is your source website called http://sharepoint/ and your target is called http://sharepoint/targetmanagedpath ?
• Are the managed paths the same?

Scenario 1: Different managed paths

In the case of different source and target managed paths, it’s impossible to directly attach the content database to the target web application.

1. In order to successfully attach the content database, create a new –empty- web application. Empty means that there are no site collections created in the attached content databases of the web application.
2. Attach the restored contentdatabase using the following command:

   Mount-SPContentDatabase -Name "RestoredDatabase" –WebApplication http://emptywebapp/
   

   When the command is finished you get info about your new database:

3. If your source farm has a different version than the target farm, you have to run an extra command to upgrade your contentdatabase to the right version:

   $db = Get-SPContentDatabase | ?{$_.Name –eq "RestoredDatabase"}
   Upgrade-SPContentDatabase $db
   

   The upgrade process might generate errors. The most common cause is that the source web application’s solutions aren’t deployed on the empty web application. You may safely ignore this error.

4. Now that your content database is attached it’s time to move the site to the correct web application and managed path.

   Backup-SPSite http://emptywebapp/ -Path C:\TEMP\backup.bak

   Restore-SPSite http://sharepoint/site -Path C:\TEMP\backup.bak

   Make sure that when you restore your site, you target the right contentdatabase. You can use the –DatabaseName switch to specify where to restore the site collection on the target web application’s content databases.

5. Make sure that you clean up after your restore was successful.
   • Delete the temporary bak file
   • Delete the restored content database
   • Delete the temporary web application
   • Delete the temporary web application’s content database

Scenario 2: Same managed paths

When the source and target web application’s site collection have the same managed path, it’s possible to directly attach the restored database to the target web application. You do this with the following steps:

1. Attach the restored contentdatabase using the following command:

   Mount-SPContentDatabase -Name "RestoredDatabase" –WebApplication http://emptywebapp/
   

2. If your source farm has a different version than the target farm, you have to run an extra command to upgrade your contentdatabase to the right version:

   $db = Get-SPContentDatabase | ?{$_.Name –eq "RestoredDatabase"}
   Upgrade-SPContentDatabase $db
   

Result

When a site is moved from production to another environment, all it’s content is moved. Take into account that data might also reside in other places like the managed metadata term store.

Site Collection Removal Error: System.IO.DirectoryNotFoundException

While creating a new site collection using the Central Administration page, we encountered an error whilst waiting for the “Processing…” window to complete. Fair enough, we looked at the logs, fixed the issue and tried the whole process again.

Seems that in the previous action, a site collection reference already has been created somewhere in the web application configuration. Although there’s a reference, the necessary files to render the page aren’t there. There’s also no possibility to remove the existence of the site collection. When you try to do something with the site collection, for example try to delete it, you always get the following exception:

System.IO.DirectoryNotFoundException, <nativehr>0x80070003</nativehr><nativestack></nativestack>

One solution is to remove the content database, and recreate the content database and site collection with PowerShell. Using the GUI will break things again.

If that doesn’t work, I found 2 other workarounds for the problem:

1. Delete the web application and recreate it. This is not a good solution, because you create downtime, lose managed paths, configuration, etc.
2. When you encounter the error on the “Processing…” page, leave the window open to preserve your session. Fix the issue that shows up in the log, and simply hit F5 and use the same session. This will complete the creation process of the site collection and not throw any exception.