SharePoint 2010, like any complicated product this day and age, needs to be patched from time to time. Not only is it tough keep an existing farm up to the current patches, it can be tough to get them installed on a new farm. Fortunately, even though it’s not Christmas, Microsoft has given us a great gift, the gift of slipstreaming. Slipstreaming itself is nothing new, we could do it to Windows NT back when we had to walk uphill both ways to the server room. It hasn’t gotten a lot of attention in SharePoint though. I’m going to fix that in this blog post. Front and center Slipstreaming, today is your day to shine!
Tell Me More
There’s not much to Slipstreaming patches and I’ll cover that process at the end of this blog post. Before I do though, I want to cover a few questions that should come up as you start playing with it.
Q: What’s the big deal, what does slipstreaming get me?
A: Mainly it just saves you time and trouble. When you slipstream the patches you just install SharePoint and it is magically patched, say to the August 2011 CU level (14.0.6109). If you didn’t slipstream you’d have to run the install, then install SP1, then install the August CU. You don’t have that kind of time.
Q: Can I slipstream both Service Packs and CUs?
A: Absolutely! Just make sure you do them in the order they were released. I’ll show how to do this below.
Q: No I need to slipstream both the Foundation and Server patches into the install?
A: No. The SharePoint Server (or Project Server for that matter) patch includes all the binaries that exist in the Foundation patch.
Q: Can I slipstream a language pack into the install?
A: No. You must install them separately. However, you can slipstream a language pack’s patches into its install.
Q: That’s bad news, what about the Office Web Apps?
A: Same story. You can’t slipstream the OWA install into SharePoint, but you can slipstream the OWA patches into the OWA install.
That should be it. If I get more questions in the comments part of this post, I may add them above. I never read the comments in other people’s blog posts, so I assume none of you do either. 
Now on to actually slipstreaming.
Slipstream For the Masses
Here are the steps to slipstreaming a patch into a new SharePoint install. I’ll be slipstreaming both Service Pack 1 and the August 2011 CU. You can find all the patches and their download links here. Here’s what my install directory looked like:
Normally when we install SharePoint we double-click OfficeServer.exe and go to town. If we want to slipstream some patches into the install, we need to extract it out. To do that I created a directory in D:\Install called SP2010. Then I extracted OfficeServer.exe to that directory with this command:
OfficeServer.exe /extract:.\SP2010
When it was extracted, it looked like this:
We’re most interested in the Updates directory. Its contents give us some idea how to use it:
Place patches here? Don’t mind if I do. First, we’ll put the SP1 patch in there with this command:
officeserver2010sp1-kb2460045-x64-fullfile-en-us.exe /extract:.\SP2010\Updates
We’ll get a friendly message telling us the SP1 wants, need, our approval:
Once it is completely extracted we’ll get this happy news:
If we look in the Updates folder it should look a bit busier:
For each patch there’s an XML file and an MSP, which is the actual patch. If you have an Update folder full of files you can determine which patch it is by looking at the properties of any of the MSP files in the directory.
This also exposes that you can patch individual pieces of SharePoint. For instance, if you double-click that particular MSP on an existing SharePoint installation, you’ll update the Access Services piece, but nothing else. Don’t do that.
Some blogs would stop there. Not me. I’m going to take it one step further and show you how to slipstream your slipstream. At this point SP1 is nearly five months old and there have been three CUs released since then. Let’s put one on, shall we?
The technique is exactly the same for the CU. Run it with the /extract parameter and dump it in the same Updates directory:
office2010-kb2596505-fulfile-x64-glb.exe /extract:.\SP2010\Updates
Notice that the SP1 executable ends with “en-us” and the CU ends with “glb.” The former means SP1 is only US English and the latter means the CU is Global, containing US English and everything else. Service Packs only contain one language, CUs contain them all. That’s why SP1 is 396 MB and the CU is 1,103 MB. It contains more files. This is also evident if we look at the Updates directory. It now shows files that are not us-en or x-none.
At this point our slipstreaming adventure has come to an end. All the commands we typed look like this:
Go ahead and run the Prerequisites and then install SharePoint by running setup.exe from the SP2010 directory.
The install will continue as normal. It will spend a lot more time on the “Applying Updates…” part:
Once it’s finished continue as normal. Either create a new farm (with PowerShell, of course) or join your existing farm.
If you do need a language pack, follow the same steps. Extract the language pack install, extract its service pack and then extract the CU into the same Updates folder. If you’re installing the Office Web Apps, again, the same process. Extract the OWA install, extract its service pack then its CU.
That’s all there is to it. Hope that helps some folks out.
tk