You’re creating a new Service Application, and in the “use an existing application” pool drop-down menu you see listings for many application pools that don’t actually exist in IIS.
How this happened:
You probably created many Service Application Pools when creating old Service Applications that have since been deleted. After you told SharePoint to remove the Service Application, there was an unused Application Pool in IIS that you subsequently removed manually.
How to clean this up:
Open a PowerShell window that has the Microsoft.SharePoint.Powershell snap-in loaded, and use the Remove-SPServiceApplicationPool “APP POOL NAME” command to tell SharePoint that those old application pools no longer exist. The next time you try to create a new Service Application, those old nonexistent options will be gone.
Happy Sharing and Pointing.
This only applies to Site Collection backups, and not farm backups. Farm backups are apparently just fine as long as you run the psconfig update command afterward. I haven’t had to deal with these specifically yet, and if those have the same issue then I’ll post at a later date (when I come across those issues).
If you have a site collection backup from before a service pack was applied, you can not restore from that backup after the service pack. What you’ll want to do is to set aside another environment (even if it’s a virtual image) from before the update in case you need to restore one of these old backups in the future. After you have the content database restored with the site collection in it, you can attach to the new environment and run psconfig’s update to get it up to speed.
The pre-SP1 environment I stood up for this purpose was a Windows 7 developer install of just Foundation on no domain at all. The final destination was in a domain running server.
Yes, I just had to do this. Yes, it was a huge hassle. Yes, it worked.
When installing SharePoint for the first time, there is an option to use either NTLM or Kerberos. Kerberos is recommended, but the caveat that they give you is that additional steps need to be taken by an administrator to make it work.
On older server versions (Windows Server 2003 R2, for instance) you could pick Kerberos from the get-go and continue setting everything up as long as you were logged in as an Administrator. Later on you’d find that nobody else could log in until an administrator set up the SPNs, and at that time you’d be setting them up (typically via command line).
If you’re installing SharePoint 2010 onto Server 2008 R2, though, Central Administration won’t even load until those same SPNs are set up. This post is intended as a quick walkthrough of how to do it if what I just said made no sense.
In our case (for our test environment) we’re using the domain abcuniversityph.edu (does not exist – we just use this sample for class), have gone through the steps to install SharePoint, and have told it to use Kerberos for authentication. We then tried to load Central Administration and it wouldn’t allow us to log in.
Our next step is to use the ADSI Edit utility, which can be launched by typing adsiedit.msc in the search/run textbox from the start menu.
When that comes up, we need to locate the Administrator Container.
As you can see, we had to go to our domain, then choose the Users Container, and found Administrator in there.
At this point we’ll right click on the Administrator container, and choose Properties. From there, we locate the servicePrincipalName property and edit it.
For our example, the necessary line to add (just for Central Administration) was the http/abcuniversity.abcuniversity.edu:7777 line, as our Central Administration Web Application happens to be running on the lucky port 7777. Note that it takes the form of protocol/fully qualified computer name:port. We also added a line for the computer name on port 80 (by leaving the port off) so that the demo web applications that we create are also accessible.