SharePoint 2010 Remove Orphaned Application Pools

I was trying to create a new Managed Metadata Service Application (CA -> Manage Service Applications -> New dropdown (in the ribbon) -> Managed Metadata Service. I filled out the modal window and clicked OK. It all seemingly went through fine and the newly created Manage Service Application showed up in the list. However, it actually went seriously wrong in the backend. There was no database created in SQL Server and no application pool created in IIS. The problem, as logged in the Application Event Log, was because the Managed Metadata Web Service had not been started (CA -> Manage Services on Server).

Anyway, the problem now is that SharePoint thinks there's an application pool with the name but IIS does not have it. So the name is orphaned in SharePoint. It's not a problem if you don't ever select it but I'd like to keep things clean. so here's how to get rid of it:

1. Go to the config db, run a query like "select * from Classes where FullName like '%pool%'". This gives you two records, one for regular web apps and one for service apps.
2. Now run another query "select * from Objects where ClassId IN ('Id1FromAbove', 'Id2FromAbove'). This gives you the list of all application pool defs.
3. Find the one with the orphaned name, and delete it (could have searched for this name directly but checking the IDs made sure the object is indeed the app pool).

Go back to CA and try to create a new Service Application, the orphaned app pool name is no longer in the dropdown. Of course editing the config database directly is often a no-no. hey, what else can I do, Microsoft?

Messed up Security Policy (0:BAG:BAD), now what?

Don't exactly remember what got me to look at Component Services -> Local Policies -> Security Options -> DCOM: Machine Launch Restrictions in Security Descriptor Definition Language syntax. Maybe trying to enable the grayed out Local Activation options for IIS WAMREG as what I discussed in the previous post (which is the correct way!). So this policy shows "Not Defined". I probalby read the wrong blog or something, so decided to click Edit Security on the Properties window of this policy, and removed all the entries in Group or usernames. As soon as I clicked OK, 0:BAG:BAD showed up in the Security descriptor box. Now even after I went back and added back the groups and users, this 0:BAG:BAD entry would not go away. And weird things start to happen after a reboot, like the Windows Explorer wouldn't start anymore, giving a permission error. Many posts suggest to repair the windows install, or run secedit to reset the security (http://support.microsoft.com/kb/313222) . Now this is my Windows 2008 R2 SharePoint VM, so I know if I reset security, SharePoint would stop working. I had no choice but to give it a shot. No! resetting security didn't fix this, and sure wiped out other security settings that SharePoint needs.

Then I figured it out purely by luck. The value of the Security Descriptor is in fact stored in the registry. Simply right click Security Settings at the top in the Local Security Policy window and select Export Policy. It creates a .inf file with all the registry locations of the policies. Go to RegEdit, find it, and delete the entire string value entry (the one with 0:BAG:BAD), restart Local Security Policy, voila! the Policy is set back to "Not Defined"!

The importance of owner for some registry keys - DCOM Launch and Activation

Very often application such as SharePoint Server and SQL Server are installed with the Administrator account right after an OS build in a dev/VM envrionment. Then the VM is joined to some domain, and you switch to use a domain account that's added to local Admin group. All is fine. From time to time, you may get a local activation permission error, like this one for SharePoint:

The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID

{61738644-F196-11D0-9953-00C04FD919C1}

to the user \mossService SID (S-1-5-21-). This security permission can be modified using the Component Services administrative tool.

That GUID is the ID for IIS WAMREG Admin Service. So you go to Component Services -> Computers -> My Computer -> DCOM Config -> IIS WAMREG Admin Service -> Properties -> Secuirty tab, ! everything's grayed out! How do you change it?

The reason is that despite being logged in as an account with local admin access, the particular security registry key is readonly. THE correct way to make it writeable:

1. Start regedit (please disable UAC, which is troublesome on server)
2. Go to the key [HKEY_CLASSES_ROOT\AppID\{61738644-F196-11D0-9953-00C04FD919C1}] , or the key with the GUID that you're trying to modify.
3. Right click on the key -> Permissions. If you select Administrators and click Full Control and Apply, it doesn't let you do it.
4. Click on the Advanced button, go to the Owner tab, change to Administrators (or the currently logged in account, or another account/groups). OK
5. Back on the Permissions window, now you can give the Administrators group Full Control.

After done the above, exit Component Services, and start it again, go to IIS WAMREG Admin Service, now you can change the settings of Local Activation etc.