HTTP Error 403 – Forbidden with Custom or Updated Features and Application Pages
Posted: August 31, 2009 Filed under: Best Practices, Development, Feature Development, Features, IIS, SharePoint, Troubleshooting Leave a comment »This is a fairly common and non-descriptive error that continues to surface more and more as the SharePoint developer community continues to grow. Surprisingly, I’ve found very little information in the web regarding what I believe to the most common cause and solution (hence this blog post).
Many things can trigger this error, and as you might expect by the description the error is security/permissions related. I’ve seen it most often, when browsing the Site Features and Site Collection Feature pages… but it has been known to take down a whole site; although mostly (and luckily) in dev environments.
So why do I keep referring back to development? And more importantly, what is this “most common” cause/solution? Its mostly tied to “drag and drop”; when you drag and drop files, permissions usually go with them (albeit there are a few exceptions.) With development rarely taking place directly in the 12 hive features, or layouts folder; its shouldn’t be surprising to see developers (and administrators alike) deploying and often testing changes to features by dragging and dropping files from their Desktop, My Documents, or project folders. Naturally this approach doesn’t follow best practices, but I wont deny having made the mistake while testing a quick change to a feature or elements xml file in a development environment. All updates to production environments should be done via WSPs.
So how do you solve the problem? Finding the culprit shouldn’t be too difficult, think of any items that have been recently deployed/updated. Cant think of any, search for any recently updated files of folders. If you do think of or find any; check the permissions and make any required modifications; also consider redeploying them via a WSP.
So what’s my Web Application Pool Process ID (in Windows Server 2003)
Posted: April 15, 2009 Filed under: IIS, Tools and Utilities, Troubleshooting 3 Comments »Have you ever noticed your WFE server crawling, and then ran Task Manager to find the Memory Usage of some of your w3wp.exe process through the roof. You need to know which process is tied to which application pool to begin troubleshooting. How do you get this information? OK, so this is nothing new, and definitely not specific to SharePoint. But it does come in handy, and I never seem to remember exactly how:
1. From Task Manager, select View > Select Columns
2. Put a check mark next to “PID (Process Identifier)” and click “OK”
3. Open the command prompt
4. Run the following command:
%systemroot%\system32\cscript.exe %systemroot%\system32\iisapp.vbs
The above should result in an output similar to the following:
Notice how each w3wp process is tied to a specific application pool. If you’ve properly labeled your Application Pools and are not using the same Application Pool for all of your IIS sites, this should give you a good place to start looking for problems. If responsiveness is severely hampered you may choose to recycle the the offending Application Pool without having to do an IIS Reset which would impact all of your other sites.
Retrieve the IUSR (Anonymous) password using the IIS Resource Kit Metabase Explorer
Posted: January 9, 2009 Filed under: Administration, IIS, IUSR, Metabase, Troubleshooting 7 Comments »Just recently, while troubleshooting an 401 Unauthorized error on an FBA site in SharePoint, I discovered that someone accidentally changed the password of the IUSR account (IIS Anonymous User) on one the IIS Web Sites.
The error in the browser was “HTTP Error 401.1 – Unauthorized: Access is denied due to invalid credentials.” I’ve blogged about this sort of error before, and there can be many culprits. But having gone over the scenarios I know of that might cause this with no luck, I decided to look at the Event Viewer Security logs.
I quickly discovered a series of Failure Audits with event IDs 680, 529, 539. Event ID 529 was the one that caught my attention:
Logon Failure:
Reason: Unknown user name or bad password
User Name: IUSR_…
The problem was very apparent; there was an issue with the credentials being supplied by the IUSR account. I tested with another number of sites non of which generated the error, so it was definitely isolated to this particular web application (IIS Web Site). I verified the User Account and it was fine, so it had to be the password. I searched the web for a way to retrieve the IUSR account password and everything seemed to indicate that I should use the adsutil.vbs script (which works well, just remember to change “IsSecureProperty = True” with “IsSecureProperty = False“.) But I also saw a comment referencing the “Metabase Explorer”; very cool.. something that would let me browse through the IIS Metabase.
I downloaded and installed the IIS Resource Kit and used it to retrieve the password of the IUSR account (IIS Anonymous User.)
After installing the IIS Resource Kit, follow these steps to retrieve the IUSR password using the Metabase Explorer:
- Open the IIS Metabase Explorer by going to Start > All Programs > IIS Resources > Metabase Explorer > Metabase Explorer
- Go to the “View” menu and click on “Secured Data” (this will make sure the password is not displayed as asterisks) and Inherited Data (this will display any data that the web site is inheriting from the default)
- Expand the W3SVC Branch
- Expand the Branch of an IIS site that is running anonymous access
Note: To determine the ID of the IIS Site; select the “Web Sites” node in IIS and look for the Identifier column in the right pane.
- Select the “Root” node and look for the AnonymousUserPass property in the right pane.
