User unable to create a new My Site

Last week I had to take a short break from dealing with the newer versions of SharePoint, to do some troubleshooting on one of the few SharePoint 2007 environments we are currently still maintaining. The customer in question is migrating to SharePoint 2013 soon, so don’t worry ūüėČ

However, the solution for this problem is applicable to SharePoint 2010 as well as SharePoint 2013.

One of their employees had accidentally deleted her My Site. Obviously, my first reaction was to have my contact simply instruct the user¬†to create a new My Site by clicking on the ‘same link she normally would to access her ‘My Site’ ¬†if ¬†it hadn’t been deleted.

Easy, right? Nope…

Unfortunately, the user had already tried that and was presented with a not so helpful on-screen error message:

Your personal site cannot be created at this time. Contact your site administrator for more information.

Troubleshooting:

I first tried to navigate to her My Site, by manually adding her username to the relative path we are using for the My Sites, during which I was presented with a 404 status.

After having checked her user profile in the Shared Service Provider (SSP) and noticing¬†that the property ‘Personal site’ had¬†the following value: SPSSITEERROR¬†I removed the error value and asked her to try again. Nothing.

Other users weren’t reporting similar issues, so it was safe to say that¬†this was a user specific problem which had¬†nothing to do with the base configuration of the My Site host, configured permissions, any of the timer jobs that are involved in the creation of a My Site¬†or any other¬†configuration. The content databases attached to the My Site host had not reached their limit and the SQL server was not out of capacity. Also, her old My Site could still be found via the search.

I checked all the relevant logs –¬†ULS log, the application log and the crawl log – ¬†and the last¬†two contained¬†the more descriptive error messages I needed to solve this problem:

hresult 0x81070504

Conclusion: her My Site was deleted, but there was still some reference to it in the farm.

As error messages in SharePoint are not always reporting what is really happening (I’m very certain you can all relate to this), I decided to make sure by using the following STSADM commands from an elevated command prompt:

stsadm -o databaserepair -url [url of My Site web application] -databasename [content database containing the My Sites] -deletecorruption

result: <OrphanedObjects Count=”0″ />

stsadm -o deletesite -force -siteid [GUID of the My Site] -databaseserver [SQL server on which the content db is stored] -databasename [content database containing the My Sites]

result: There is no site collection with Id = [GUID] in content database [content database containing the My Sites] on database server [SQL server on which the content db is stored].

The GUI alternative is to access the site-collection list from the CA site and looking up the My Site of the user in question. The detail window of the My Site of the user will still be retrievable via the URL search, but the window displaying more details will be empty:

Central Administration > Application Management > Site Collection List

 Solution:

As reported earlier, the user had deleted her My Site. When you delete an object – site, list, document library, etc. – from SharePoint, the object is¬†removed from the content database it’s stored in and from the SharePoint Config database for the farm, which holds a¬†site map with unique references to the objects, used within the SharePoint farm.

In this case the My Site site had been deleted successfully from the content database, but the site map reference to the object was not removed by the timer job initiated for this purpose.

The easiest and, maybe even more important, supported method to remove this error is to first remove (detach) the content database which had the faulty My Site stored, which is still being referenced, from the web application host and immediately after that’s done re-attaching the same content database.

This can be done from the CA site:

Note: with these steps you are going to remove (detach) the content database containing a lot more site-collections than only the faulty one. Although the activity should not take more than 15-20 minutes, before doing this you should keep in mind that the My Sites that are in the content database you are going to remove (detach) will be unavailable. To prevent any further corruption of other My Sites, I took precautionary measures to stop accepting any new user sessions from being sent and gradually took the farm offline. Quite a disruptive method, but I had a maintenance slot, so this worked for me.

Central Administration > Application Management > Content Databases

  1. Select the My Site web application host from the drop down
  2. Click on the Content Database name that contains the faulty My Site stored, which is still being referenced
  3. Make sure you take note of both the Database name and Database server(+instance) and any non-default configuration that might apply to your My Site web application host, for later use
  4. Check the check box in the category ‘Remove Content Database’ and click OK twice
  5. Confirm the Content Database you just removed is not showing in the overview anymore
  6. Click on the link ¬†‘Add a content database’
  7. Enter the Database Server, Content Database and any other details you noted at point 3 and click OK
  8. Confirm that you’ve added the¬†correct Content Database
  9. Go to the user profile of the user in question stored in the SSP and clear the¬†SPSSITEERROR value from the ‘Personal site’ property and click ‘Save and close’

Since you’re in the CA site anyway at that point, you can then visually confirm the My Site reference has successfully been removed by accessing the ‘Site Collection List’ and performing a URL search for the My Site in question. You should get a message that looks similar to this one:

No site was found that begins with: {search terms}

Don’t forget to execute a profile import and crawl of the content sources, so the changes are reflected on all endpoints and in the search result. Due to some (unrelated) other factors I had to execute both a full profile import as well as a full crawl, but executing incrementals in both cases might do the trick as well.

After doing all this, the user was able to successfully create a My Site again.

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s