One question I get asked a lot from customers is around patching their SharePoint environments. In general you were always able to install the bits on all your servers in any order you felt like going.. the real question or issue I have found is the completion step which is running the Configuration Wizard. Some customers went so far as to run the installer to load the bits on their boxes but may have only run the Configuration Wizard on one box… or in some cases maybe in a larger farm they simply omitted a box.. this puts your environment at risk.
In SharePoint 2010 I still like to hit my main server that's running CA first with Config Wizard (or PSCONFIG if you choose that method) But there is nothing stopping you from going to the other boxes and kicking off the Config Wiz while the other is running…. What will happen is that the other boxes will go into a locked state for the upgrade. Once one box completes the others will in sequence of starting the Config Wiz run through the 10 step upgrade. As you can see in the screenshot below this particular box is waiting for the lock to release to continue.
The one real take away I need to make is to ensure in a multi-server environment you run this on each server.
Building a brand new SharePoint 2010 Environment? Want to decrease some of the time for making sure your environment is up to date with regards to versioning? Slipstream your build.
In the following section I am going to detail how I build my slipstreams… there are other posts out there that will be similar and may even include shortcuts such as posting the bits directly to the update folder but I like to be a little more hands on and in reality it does not take a lot of effort.
New Environment
Download the SharePoint 2010 RTM Bits (http://technet.microsoft.com/en-us/evalcenter/ee388573)
I shorten the name of the downloaded file before I begin to something like SP10.exe and SFSSP1 this will make it a bit easier on the typing.
Download the SP1 Bits.
Although technically not necessary I will still download and incorporate both the SharePoint and the SFS SP1 Bits into my slipstream.
http://www.microsoft.com/download/en/details.aspx?id=26623
http://support.microsoft.com/kb/2460058
Same as with the RTM bits… I will shorten the names of these files to help with typing. SFSP1.exe and OFFSP1.exe
Download the CU's
http://support.microsoft.com/kb/2536599
http://support.microsoft.com/kb/2553931
Lets get busy
So this was the hardest part of the operation. What I do next is create four folders and extract the bits for each into them.
SP1 – Folder names OFFSP1 SFSSP1
Command I run: sp1.exe /extract:c:\OFFSP1 (where sp1.exe is the renamed executable and OFFSP1 is the folder I created and am extracting to.
Sfssp1.exe /Extract:c:\SFSSP1
I will do this for the Cumulative Updates as well.
Once this is complete the SharePoint 2010 Installation folder has a folder called updates. I am simply going to copy and paste the contents of each of the folders I extracted directly into Updates.
This concludes the Slipstream procedure. Once complete you can go forth and install. Your environment will be up to date and you wont have to go through the process of individually installing patches and then remembering if you hit every server in the process… It happens (unfortunately very often)
Additional reference information can be found here at my buddy Spence's site http://www.harbar.net/archive/2011/06/30/327.aspx
Came across this today. My buddy Ryan Campbell wrote up a nice piece that i felt could use some more exposure.
Virtualization, the SAN and why one big RAID 5 array is wrong
Have a read... its a goodunn
Cheers
In my day to day work as a PFE I engage quite often with customers with sessions on Upgrading to SharePoint 2010 or performing SPRAPs (SharePoint Risk Assessment Program) on environments. When performing either of these I tend to come across a lot Configuration DB Orphans. When running the command stsadm –o Preupgradecheck on a MOSS 2007 (SP2) environment you may see the following output
Failed : Orphaned site collections
An orphaned site collection is a site collection exists in the content database, but it is not in the configuration site map. Such site collections is not accessible and will not be upgraded properly.The follow orphaned site collections where found
This further goes on to tell you how to fix the issue in the next line you would see in the output report:
Try detaching and re-attach the content databases to fix the orphaned site collections.
SO you may ask…. Well how did I get these orphans anyway and how will they affect my upgrade. To answer the upgrade question it shouldn't. Why you may ask? Because now you have more than enough information to correct this issue before you even attempt the upgrade J. To be perfectly honest the only way I can see this really causing an issue is if you do an In Place upgrade because the vanilla In Place we are not taking our detatching our databases and reattaching them over to a new farm (A much preferred method btw).
To answer the question on how did they get there….. well there could be a number of reasons why this happened. Duplicate URLs or Duplicate Host Headers not being in the site map. It could also be something as simple as a site deletion that occurred within a site collection that may have shown that it was deleted when the site owner made the change but tossed an error in the end…. You're left with a site that is still registered within in the SharePoint Config DB but not something that you can see or open. Were left with something I call a ghost URL.
The takeaway here is twofold. First off it's not difficult to clear this flag. And when you are looking at performing an upgrade you really want to make sure the Preupgradecheck reports back clean. Take the time to deeply analyze this report and start actively correcting the issues found. Once you clear errors re-run the Preupgradecheck to see if the changes are reflected. I have done upgrade talks where we spend half a day just going through this report and then come up with a plan for mitigation.
Some real decent videos just published on TechNet showing how MSIT does SharePoint
Managing a Parallel Upgrade to SharePoint 2010
http://technet.microsoft.com/en-us/edge/gg551715
http://technet.microsoft.com/en-us/edge/gg552996
http://technet.microsoft.com/en-us/edge/customizing-the-user-experience-with-fast-search.aspx
This information has been posted from the Product Group around some issues that are happening in SharePoint farms that have implemented the October Cumulitive Updates.
Here is the Warning
http://blogs.msdn.com/b/sharepoint/archive/2010/11/05/critical-information-about-the-sharepoint-server-2010-october-cumulative-update.aspx
Here is the workaround
http://blogs.msdn.com/b/sharepoint/archive/2010/11/06/details-and-workaround.aspx