Microsoft always puts on a great show, and late May’s TechEd North America in Atlanta was no exception. And as a SharePoint guy, my focus is always on SharePoint announcements and we got a doozy this year.

Microsoft announced that Service Pack 1 (SP1) for SharePoint 2010 would be released “in late June 2011.” This is great news. It’s great that it’s coming out soon, and it’s great we got some lead time to plan for it. In this article, I’ll cover a couple of SP1’s more exciting features, and more importantly, I’ll cover what you can do to get prepared for SP1’s arrival.

SP1’s main emphasis is bug fixes. Unlike the bimonthly Cumulative Updates (CUs) that come out for SharePoint 2010, SP1 has gotten rigorous testing and should be installed regardless of whether or not it addresses issues your SharePoint 2010 farm has.

CUs, on the other hand, should only be installed if they address an issue your farm is experiencing. SP1 should find its way onto everyone’s farms sooner rather than later.

Now, I know what you’re thinking: There’s nothing exciting about bug fixes, especially if you don’t happen to be hitting the bugs that are getting fixed. To sweeten the pot, and encourage us to install SP1 anyway, Microsoft is also adding some exciting new capabilities. I won’t cover them all here; you can get the full list from the SharePoint team blog. To whet your appetite, though, I will mention a couple of my favorites.

SP1 will introduce a site collection and Web-level Site Recycle Bin. We’ve been able to recover items, documents, lists and libraries from the Recycle Bin since SharePoint 2007, but we’ve never been able to easily recover websites or site collections without third-party tools. It will now be part of the product.

SharePoint will also get its Storage Manager page back. In SharePoint 2007, we had a page to which we could go to see how much space lists and libraries took. That page, storman.aspx, will make a triumphant return in SP1.

Those two new features alone are worth the time it will take to install SP1. Now that you’re excited about installing SP1, what can you do to get prepared? I’m glad you asked…

Test first, then install
While you should install SP1 on your SharePoint 2010 farm, you should not do it without proper testing. That means installing it in a test environment and kicking the tires a bit. Try out the new functionality, see how it works. Try out the old functionality, make sure it still works. It shouldn’t take much to convince you this all works best in a test environment, not your production environment.

Before SP1 becomes available, get your test environment set up and ready. You have a few options here, depending on how dirty you want to get your hands. If you want to grab a ready-made SharePoint 2010 environment, you can use a Hyper-V image that Microsoft provides. I’ve created a short URL link to it at http://toddklindt.com/sp2010demovm. Once you download all those files and unzip them, you will have a working SharePoint 2010 environment.

If you want, you can build your own test environment. You can build it by hand or use any of the great SharePoint 2010 automation tools available on the Internet. Autospinstaller is a good candidate, and can be downloaded here. If you install a new test environment, make sure you use different service accounts. You can see a list of the recommended service accounts at this page.

The moral of this story is that there are a lot of ways get the test environment installed, but then what? After your test environment is running, you need to get it as much like your production environment as possible. If you have any of the CUs installed in production, you’ll need them in test, too. If you need a reminder of how to find your current build number and where to find the CUs, you can find a list here.

After the build numbers are the same in test as production, you’ll also need to install any third-party software in production as well. Finally, recreate your production Web apps and service apps in test. SharePoint is pretty understanding about swapping databases between farms.

There are several service applications that will let you use existing databases when you create a new service app. This lets you populate your test environment with production service app information. The following service applications support this: Secure Store, Performance Point, Managed Metadata, Business Connectivity Services and User Profile Service. Just copy your production service app databases to your test SQL instance, and then use those names for the database names when you create the test service apps. It’s almost too easy.

The last step is to copy over your content databases. After you’ve recreated your Web applications in test, detach all the content databases that were automatically created and mount your production content databases. If you don’t have room for all of the content, bring over a good subset to test with.

After test your environment is created and populated with some good content, take a snapshot of it. You’ll want to be able to get it back to a known good state before you start torturing it. Once you have a backup plan, you’re ready for SP1.

#!
Get users involved in testing
Once SP1 comes out, install it in your test environment as soon as you can. Then let the testing begin. It’s always a good idea to not only have IT involved, but let the business users get in on the fun too. Have them check out their sites in the test environment. Have them make sure any crazy stuff they’re doing still works, and verify any third-party software made it through the service packing unscathed.

Not only does this lighten the load on IT, but it gets the business users invested SharePoint’s success. That never hurts.

After your testing is complete, you’ll know where the trouble spots might be and you’ll be practiced and prepared to put SP1 on production. And the chances of it being successful will be much higher.

Todd Klindt is a senior SharePoint consultant at SharePoint911, and has written several books on SharePoint, and maintains a blog.