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.
No comments:
Post a Comment