Oops. How NOT to restore a SharePoint site collection

So remember how I mentioned that I had just enough knowledge to be really dangerous?

I got bit by that this weekend and wound up causing an outage on one of our production sites. I ran into some behavior with the stsadm restore command that I wasn’t anticipating.

I was migrating a site from one web app to another using backup and restore. Let’s call this site oops.

So I used stsadm –o backup and made a nice little .cmp file like so

stsadm –o backup –url http://oldwebapp/oops –file c:\oops.cmp

Then I created an explicit  managed path in my new webapp to house my migrated site collection. So far so good. Here’s the command I ran to do the restore.

stsadm –o restore –url http://newwebapp/oosp –file c:\oops.cmp -overwrite

This is where the pain began. As you can see, I mistyped the last part of the URL. I also (unnecessarily) used the –overwrite flag. I’m sure you can see where this is heading. Since there was no oosp managed path, SharePoint very helpfully overwrote the http://newwebapp/ ROOT site instead! I found out about 1 minute into the restore when our monitoring site sent me an email telling me the site was down.

I then got to bug our DBA on the weekend to ask her to roll back the content database. Then I got some practice using the restore technique outlined at Emad Magdy's blog post. Good times!

The moral of today’s story? Don’t be lazy. Never use the –overwrite flag in your production environment.

SharePoint MySites for Noobs - Pt 1

Sharing MySites across SSPs

Whew. 60 days and a 1 week admin class from Mindsharp later, I've got just enough knowledge to be really dangerous.

I've had lots of fun with the day to day maintenance of the site.I even got to run an impromptu test of our backup strategy after one of our power users deleted his site collection. It's time! I'm ready to implement my first big change in production.

We've identified an app in our farm that needs to be isolated with respect to search. Let's call this app PrivateSite. We don't want search results for PrivateSite showing up in our other SharePoint apps, ever. Or vice-versa for that matter.

Armed with my 2 whole months of SharePoint experience, I now know that the way to accomplish this is by setting up a new Shared Service Provider. No Problem! We did this in the training class and it's easy-peasy! Just set up the following resources

• A new Web App for the Share Service Admin site
• A new App pool for the SharedService Admin site
• A new database for the SSP site
• A new database for the SSP itself
• A new database for the new SSP's search service.

See. Only 5 new resources, all with their own configuration, etc.

So...about 2 hours later, I have all this set up. Except oops...what about MySites?

It's not clear when you're setting up an SSP how you should handle MySites. Here's what I did to begin with. I configured my new SSP, and in the little widget that asks that you select a webapp to host your MySite, I picked our current mysite provider web app. I clicked OK to create the new provider, and then got a warning telling me that the mysite app would be associated with my new SSP. I clicked OK, waited for the new SSP to be created, and once it was, I used the Shared Services administrator to re associate the MySite application with the original provider. I then moved PrivateSite into the new Service Provider. I scheduled the search crawls for the new provider and soon I was searching PrivateSite no problem. And no results from the other sites! Success!

But my MySites still need some configuration. SharePoint allows you to share MySites across separate SSPs. This means that users on a site using one SSP can have their MySite's hosted in another. You just have to enable it. First, you find the My Site Settings in your SSP's admin site. Then find and check this box and click OK.

Do this for any SSPs you want to share MySites between. Now your SSP's will allow sharing MySites. You're not done yet though.

Next, you have to tell your SSP's which users have their MySites hosted on which SSP. You do this using the SSP's "Trusted My Site host locations" setting. This is just a list with two fields. The URL of the trusted MySite, and a "Target Audience" for the trusted MySite. the Target Audience is just a list of users whose MySites are hosted on the Trusted URL. Luckily for me, my setup was simple. All users would have their MySites hosted in the old SSP. I just had to add the "All site users" global audience like so

You can use Distribution/Security groups from AD to be more specific about which users to direct to the other MySite provider. Now I can browse PrivateSite on a separate SSP, but the MySite link at the top of the page still links back to my MySite on the old SSP.

Done!

Only...it turns out, I should have asked our end users ahead of time if that's how they actually wanted the MySites to behave.

Thus...Part 2.

Statement of Purpose

I'll be posting technical problems and solutions that I run into as a new SharePoint admin. SinceI'm completely new to SharePoint, I thought it'd be neat to have a running history of my experience with the technology as I spend the next couple of months struggling to get up to speed.