First the long story of how I got here, if you don’t care about it, just skip the next three paragraphs, if you don’t know what a paragraph is, just click here.
I came upon a scenario in my development VM where my Visual Studio environment would throw the following error every time it tried to do any type of deployment/retraction from the IDE: “Error Recycling AppPool, Win32: The system cannot find the path specified.” The odd thing was that it only occurred for a specific web application, VS worked fine deploying/retracting to the other environments.
After piddling around the internet, I couldn’t find anyone that had this issue. So I was on my own from a troubleshooting perspective. Based on the error message, I figured that the issue had to do with the fact that the COM API (which is what VS uses to recycle the App Pool) couldn’t access the given Web Application’s App Pool to recycle it. So at first I looked into permissions… verified that the Administrator had the appropriate permissions around the Web Application and inside the VM. No luck. Then it came to me that I recently switched that Web App to a different Application Pool. In a development environment, having too many app pools can harm performance, so I recently consolidated. Low and behold, when I switched the web site in IIS to a different app pool, I also deleted it from IIS. That would make sense then that it can’t find the path specified… since the Web Application doesn’t exist. The issue here then was that SharePoint still thought the Web App was associated with an Application Pool that didn’t exist. I navigated to the Configure Service Accounts Page (Security –> Configure Service Accounts) and found the orphaned Web Application Pool in my drop down list. Well that’s a bummer. At this point it was getting way too “Admin-y” for me, and I have some colleagues that know a thing or two about Administering SharePoint.Fortunately, Todd was able to point me to his blog post where he covers this topic in serious detail. After getting the SPWebApplication pointing to the correct App Pool, I was in good shape. Visual Studio was able to deploy and retract and do all the cool things that we SharePoint Developers now take for granted. (Honestly, having it now work was a little like being in the desert without water.)
For completeness sake, I took a peak at the Configure Service Accounts page again and found that orphaned web application pool was still showing up in there. So SharePoint didn’t delete it automatically. Makes sense, once its deleted there’s no getting it back (this is emboldened on purpose, because I want to make sure you understand what’s happening with the following set of instructions). And that brings us to the main (and shortest) part of the post…
The collection of “Web Application Pool” objects is stored within the Web Application SPWebService object inside the SharePoint APIs. So to remove one, we need to get to that service, its collection of Application Pools, and delete the one we want. Powershell, here we come:
Three steps:
1) Get the WebService for any Web Application, List all of its ApplicationPools, and get the GUID of the one we want to delete.
2) Same Get-SPWebApplication “blah”.WebService.ApplicationPools construct, except this time we want to call Remove, and pass in the Guid we found on the command before.
3) Now its deleted! FOREVER (see previous emboldened text) so make sure you meant to do it! We confirm this by running the first command over again… you can also navigate to the Configure Service Accounts page and verify that it’s not there
anymore.