Random SharePoint 2010 Coding Discoveries - AppPool DropDownList

While tinkering with my Managed Metadata Service issues this week, I noticed that the drop down list of Application Pools in SharePoint does not always match the Application Pools listed in IIS. I decided to dig and find out how SharePoint populates that list.
I started by opening the page that creates the Managed Metadata Service, ManageMetadataService.aspx, located at C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\ADMIN, since I knew it had the list of AppPools on it already. I found the control in there, IisWebServiceApplicationPoolSection, which lives in IisWebServiceApplicationPoolSection.ascx.

That class for that control exists in the C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI\Microsoft.SharePoint.dll assembly. Inside it I found the method that was doing the work, PopulateApplicationPoolDropDownList, and gave it a look. Here are the important lines:

SPIisWebServiceSettings settings = SPIisWebServiceSettings.Default;
if (null != settings) {
 foreach (SPIisWebServiceApplicationPool pool in settings.ApplicationPools)  {
 }
}

The key there is that the property, SPIisWebServiceSettings.Default, will ultimately return this:

return (SPIisWebServiceSettings) farm.GetObject("SharePoint Web Services", farm.Id, typeof(SPIisWebServiceSettings));

That method, as you might guess, simply returns an SPPersistedObject, which is just a serialized object stored as an XML blob in the configuration database. In other words, the list is not being pulled directly from IIS, hence why SharePoint thinks I have an AppPool that IIS does not!

A little more investigating has led me to this little gem, which I will have to look into further in the future, as it may help me fill in some of the missing pieces of how the AppPools eventually make their way into IIS:

SPIisWebServiceApplicationPoolProvisioningJobDefinition.Execute(), which calls SPIisWebServiceApplicationPool.ProvisionLocal()

I am done exploring for now, but at least I know I'm not crazy - just because SharePoint thinks there is an AppPool doesn't mean there actually is one! My current theory is that the job to create my AppPool didn't run or errored out.

Managed Metadata Service fails to work and missing AppPool, Round 2

As you might recall from this post, I have been trying to figure out why provisioning a Managed Metadata Service keeps failing. I know that my AppPool isn't getting created, which is strange, as SharePoint is usually good about creating AppPools whenever it asks you if you'd like one.


As my first two attempts both attempts ended with the same issue, I decided to try some different approaches. For my third attempt, I still chose to create the service myself (as opposed to using the Farm Configuration Wizard), but rather than selecting a new AppPool, I chose an existing one, SharePoint Web Services. Surprise, surprise, that doesn't work either. Exact same error message, even though we know this AppPool exists.

In frustration, I restored from a snapshot again, but this time used the Farm Configuration Wizard with only the Managed Metadata Service checked. At the step for creating a Site Collection, I clicked Skip. And magically, it worked. How interesting that I can't use the GUI to provision a service but the wizard can. I decided to poke around and see what was different.

So far I've noticed:

In IIS

• An AppPool with a GUID name, running with the Managed Account I specified in the wizard.
• If I right click on the AppPool and choose "View Applications" I see a Virtual Directory that points to  C:\Program Files\Microsoft Office Servers\14.0\WebServices\Metadata.
• The Virtual Directory lives under the SharePoint Web Services site.
• An AppPool named "SharePoint - 80", also running with that Managed Account.
• If I right click on this AppPool and choose "View Applications", I see a site that points to C:\inetpub\wwwroot\wss\VirtualDirectories\80

In Central Administration

• A new Web Application, "SharePoint - 80", corresponding to the site in IIS
• There are no site collections in this Web Application, which is to be expected since I skipped that step in the wizard.
• Under Manage Service Applications, my Managed Metadata Service is now listed.
• Clicking on the Managed Metadata Service under Manage Service Applications displays the management screen without any errors.

In SQL Server

• A new database, named "Managed Metadata Service_{GUID}", with a very unattractive GUID in the name, of course.

So, there are two possible choices for what caused the magic, and it could be both of them. It's possible I have to create the AppPool myself. I find this unlikely, however, as the screen to provision the Managed Metadata service does prompt me to create the AppPool. I'm going to take SharePoint at its word that it is capable of creating this. The other possibility is that even if there is no existing Site Collection in your Farm, you at least need a Web Application created before you can provision the Managed Metadata service.

I plan on digging through the code of the Farm Configuration Wizard later to determine which of those steps was key.

SharePoint 2010 Installation has Missing server side dependencies errors

I've configured SharePoint with a PowerShell script at least 4 times in the last 24 hours from a clean install, and only once has it NOT had the Missing Server side dependency errors. I don't even have any services installed in the Farm yet, so the common fix of "tricking" SharePoint by opening one of the Search configuration pages is not doable. Furthermore, the list of web parts that do not have their tp_Assembly populated is quite long. The annoying part is that SharePoint actually does know where the classes live; it just can't seem to populate that column in other tables:

select nvarchar7 'Web Part', nvarchar8 'Assembly', nvarchar9 'Class' from alluserdata where tp_listid in (select tp_id from alllists where tp_title = 'Web Part Gallery')

I don't know if the configuration of SharePoint is just that flakey, or if it's specifically tied to trying to automate the configuration rather than using the SharePoint 2010 Products Configuration Wizard, but it's very frustrating. Right now the only consistent configuration experience I can get is from creating the databases with Powershell and then running the SharePoint 2010 Products Configuration Wizard to do the rest.

I've read that this is a bug that may be fixed in the RTM version of SharePoint 2010, but time will tell.

Managed Metadata Service fails to work and missing AppPool

Took my first pass at installing the Managed Metadata Service. It of course failed, with a very common error of "The Managed Metadata Service or Connection is currently not available. The Application Pool or Managed Metadata Web Service may not have been started. Please Contact your Administrator."

First thing I checked was that the service was running by going to Services on Server. It was not, so I started it, which gave no errors. Checked again and still got the error. I decided the Application Pool could be the problem since I selected to create a new one to use during installation of the Managed Metadata Service. Unfortunely, the Application Pool is not in IIS 7. I have no idea why, as if I try to provision another service it shows my Application Pool in the drop down list of available ones.

At this point the only thing I'm sure of is that I missed installing the WCF patch, KB976462. Going to reload from a snapshot and try again.

Document Sets

Interesting post from Stan Liu on Document Sets. Specifically, I find this idea very interesting, since it is very similar to a concept used in 2007 to have auto-inherited values for columns based on their parent folder.

If you have a few columns that are Managed Metadata type (this is a new column type that looks up taxonomy terms from the new Term Store), you can choose those to be Shared Columns so that all the documents within that Document Set will inherit those same attributes. 

Installation Account can't run SharePoint PowerShell cmdlets, Round 2

Part 1

Okay, explored this a little further since the error about needing to be Farm Administrator to run some cmdlets when you were, in fact, a Farm Administrator was bugging me.

I created a new account, sp_Farmadmin2. I added him to the Administrators group on my SharePoint server. Logged in as him and tried to run the SharePoint 2010 Management Shell and got my familiar error, "The local farm is not accessible. Cmdlets with FeatureDependencyId are not registered". Note that it would also not work if I right clicked and chose "Run as Administrator".

I then ran the Add-SPShellAdmin command and specified sp_Farmadmin2. Switched back to sp_Farmadmin2 and tried to run the SharePoint 2010 Management Shell again. Same error. However, this time when I right clicked and chose "Run as Administrator", it worked.

Note that sp_Farmadmin2 is NOT a member of the WSS_Admin_WPG group in Active Directory. Nor are they a member of the the Farm Administrators group in SharePoint, though as an administrator for the machine, they can get into Central Administration.


It seems there are only three keys to getting the cmdlets to work:

1. Must be an administrator on the SharePoint server.
2. Must be in the SharePoint_Shell_Access role in the SP_Config database.
3. Must right-click and chose "Run as Administrator" to start the SharePoint 2010 Management Shell.

SharePoint 2010 FBA

Apparently FBA in 2010 requires setting up your Web Application to use Claims Based Authentication rather than Classic Mode Authentication.

I can't help but have flashbacks to the presentation on Claims Based Authentication in the SharePoint Ignite sessions. Even though everyone in that room was an experienced SharePoint implementer/developer, there was a sea of mostly bewildered faces. I'm hoping that was just due to how detailed the presentation was and that the configuration of FBA is going to be much easier than trying to understand all the nuances of the theory of Claims Based Authentication.

Relevant linkage: Chun Liu on SharePoint