Deleting SharePoint Site Collections

A great post by Raymund Macaalay explains how you can re-organize your sharepoint sites and data by moving a SharePoint sub-site (SPSite) to a new site collection.  I used this method with great success to take an 80GB site collection and split some 10GB sub-sites out to their own site collections (and content databases).  During this process I had created numerous test site collections to verify the Import-SPWeb task would restore everything correctly.  Once done, I was happy to delete those site collections from the web application.

Since each of these site collections were around 10GB I was expecting a lot of free space to open up in the contentdb, which I would reclaim with a shrink operation.  However, the free space was not there.  This is because deleting a site collection from Central Administration does not permanently delete the site collection, it still exists in the second stage recycle bin which will store it for (default) 30 days.  To remove it from the contentdb immediately you need to run some PowerShell commands.

Get-SPDeletedSite will return a list of deleted sites:

You can permanently remove the sites by using the Remove-SPDeletedSite command:

Once this completes, you will still not see immediate relief in your contentdb.  This is because removing large amounts of content can be a resource intensive operation.  SharePoint has a Gradual Site Delete timer job that by default runs once daily and will gradually remove all content marked for deletion.  If you want to verify that your site is in the queue for the Gradual Site Delete job you can view the data in the dbo.SiteDeletion table of the content database.

After the site deletion job completes its work, you can use a shrink operation in SQL Server to reduce your contentdb to a desireable size.  If you have migrated sub-sites to other site collections like I did, don't forget to purge the original sub-sites from the second stage recycle bin which can be accessed from the Site Collection Administration section of the Site Settings page.

STSADM MigrateUser and Move-SPUser Quirks

It's common for SharePoint administrators to get a request to update someone's name in SharePoint as a result of marriage.  The trusty STSADM migrateuser command has been around since MOSS 2007 as a method to update references from the old account to the new account.

In my experience, AD admins tend to rename existing accounts as opposed to creating new accounts and decommissioning old ones.  Once the account has been renamed, migrateuser can be used in the following fashion to update the SharePoint profile data:

stsadm.exe -o migrateuser -oldlogin domain\originaluserlogin -newlogin domain\newuserlogin

Sometimes this command will return a message "New user account does not have valid SID history.". If this is the case, you can add the -ignoresidhistory argument and cross your fingers that you get a response "Operation completed successfully."

If you do not get a successful message, you may instead see this:
Value cannot be null.
Parameter name: userProfileApplicationProxy

Many search results will point you towards verifying that you are a farm administrator, and of course you are in the farm administrator group, so you brush this off and move on.  Some results point towards a promising PowerShell command Move-SPUser:
Move-SPUser -Identity domain\originaluserlogin -NewAlias domain\newuserlogin

Unfortunately for me I recieved the error:
The parameterless Read method can only be used when this instance was initialized with an SPUser object.

Using Get-SPUser to store the user login in a $user variable to be passed into Move-SPUser returned yet another error:
You must specify a valid user object or user identity.

So the old user doesn't exist in the web anymore, yet when I view the user profile for the user in the User Profile Service in Central Administration, the old login name is still displayed next to all the updated profile information.  Somewhere the old login is still hanging around, so back to migrateuser!

The solution for me was indeed related to the account used to run the migrateuser command. Evidently being a farm administrator is not enough, you need to use the FARM Account.  To find out exactly what this account is, open up Central Administration and click on configure service accounts under the Security heading.

Select Farm Account from the drop down box, and the page will refresh and list an account name in the bottom drop down box.  This is the account you need to log in to the SharePoint server.  I tried using the Run As Another User command on the SharePoint Management Shell and that did not work, you will get a message Access Denied when you do that.  When you login to the server, right click SharePoint Management Shell and choose Run as Administrator.

Hopefully this time you will breathe a huge sigh of relief as you see the coveted Operation completed successfully message.