<A Microsoft PFE's Note from the Field>
So in my day to day SharePoint support endeavors one of the classic cases that come in from time to time is customers trying to implement Kerberos into their Farms. One of the issues I see pop up a lot is duplicate SPN's.
The classic method (via the command line) is to run the following command to create an SPN:
Setspn –a http/<FQDN or Netbios Name> Domain\usercredential
For example Setspn –a http/connect.sharepoint.com sharepoint\content1
This would create an SPN to be used to create a valid Kerberos ticket for the http/connect.sharepoint.com site. Easy stuff here and you can verify this by going into ADSIEdit and open the properties for the Content1 Service Name.
But how do we get the issue with Duplicate SPN's. Usually this comes down to poor planning before you turn on your computer. Say as an example (and one I see often) you didn't think this through and plan your AuthN properly. Or say you just made a simple "FatFinger" or had a "Brain Cramp"… it happens. For illustration purposes lets go with the idea that you created the above mentioned SPN but for some reason you tried to run the Setspn command again using a different account. Voila! that's where we are in trouble. In my example I created two SPN entries pointing to the same site but I used two different service accounts. SPContent and SPContent1. As you can see in the screenshot below I get an Event ID 11 thrown which if you can read the text is basically telling me exactly what I need to know to go forward and fix the issue.
So is there a way to verify this before I go and run the command? Absolutly. If you enter the command Setspn –x you will get a list of any duplicates that exist in your environment.
Let's take this one step further and combine both the –A and the –X into a single FatFinger Proof method of creating our SPN's
Operation ABORTED!!! So if we look at the above output were shown the same information as the Setspn –x but we are also combining this with the ability to add an SPN. In both of these outputs you can clearly see that in my demonstration I tried to create an SPN for the same site http/connect.sharepoint.com but I used separate accounts. Also note that I can use the same account for multiple hosts if I so choose.. in this case im using Spcontent1 for both http/connect and http/my.
So in a perfect world when you are doing this work and you don't have any duplicates you can use either the setspn –x initially to see if any duplicates exist or do what I always do… use the setspn –s and cover everything in one sweep. In the above example if there were no duplicates the process would successfully finish and presto chango you have your SPNs created
Hope this helps someone out there J Cheers!
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