Mar15

SharePoint get_IISAllowsAnonymous get_VirtualRootPath  

Categories: Errors

I found a serious issue with a SharePoint implementation recently.  It turned out, there were actually 2 separate places in SharePoint where an error was occurring.  After searching extensively for a resolution, I never found an actual answer / solution.  Most posts said that although they didn’t know what was wrong, they made them go away by backing up the content database, recreating the web application, then restoring the content database.  Although I was tempted to do the same, I wanted to understand what was wrong first.

image

First things first, I needed to get a better detailed error message.  Error, wasn’t going to cut it here.  Please see my previous post on how to get detailed error messages in SharePoint: SharePoint Error Messages

The two errors:

1. Whenever I attempted to access the Advanced Permissions for a site, the following error was generated.

image

Object reference not set to an instance of an object.   at Microsoft.SharePoint.SPSite.get_IISAllowsAnonymous()
   at Microsoft.SharePoint.ApplicationPages.UserRoles.InitPage()
   at Microsoft.SharePoint.ApplicationPages.CBaseAclPage.OnLoad(EventArgs e)
   at System.Web.UI.Control.LoadRecursive()
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) 

2.  Whenever I attempted to add a Web Part (through UI), the following error was generated.

image

Object reference not set to an instance of an object. at
Microsoft.SharePoint.WebPartPages.VirtualServerWebPartDataProvider.get_VirtualRootPath()
  at Microsoft.SharePoint.WebPartPages.VirtualServerWeb PartDataProvider..ctor(SPWeb web)
  at Microsoft.SharePoint.WebControls.WebPartGalleryPicker.FindAllWebParts()
  at Microsoft.SharePoint.WebControls.WebPartGalleryPicker.CreateChildControls()
  at System.Web.UI.Control.EnsureChildControls()
  at Microsoft.SharePoint.WebControls.WebPartGalleryPicker.OnLoad(EventArgs e)
  at System.Web.UI.Control.LoadRecursive()
  at System.Web.UI.Control.AddedControl(Control control, Int32 index)
  at Microsoft.SharePoint.ApplicationPages.WebPartGalleryPickerPage.CreateChildControls()
  at System.Web.UI.Control.EnsureChildControls()
  at System.Web.UI.Control.PreRenderRecursiveInternal()
  at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

Cause of Errors
It took a good bit of trail and error, and deductive logic to discover why these errors happened.  In the end, I was a little perplexed as to why this environment was even in the configuration that it was.  Theoretically, you should never find yourself in this situation.  And that’s why there probably isn’t too much information about these errors out on the internet.  Regardless, you are getting these two errors because you do not have an Authentication Provider for an application in the Default zone. 

Example of Bad Configuration
I can’t think of a scenario where you wouldn’t have an app in the Default zone.  However, here’s how this particular implementation ended up this way.

  1. Application was created using Windows as Authentication provider in the Default zone.
  2. Application was extended into an application using Windows as Authentication provider in the Internet zone.  (site has 2 providers configured now, one for each zone)

    image
  3. SharePoint was removed from IIS Website (the 1st one in Default zone)

    image

    So now you are only left with an Authentication provider for the Application in the Internet zone.

    image
  4. Alternate Access Mappings were configured for Default.  (although AAM says Default zone, the authentication provider is still for Internet because the app in the Default zone was removed in step 3)

    image

Further Complication
You specify the zone and provider when creating / extending an application.  For an existing application, although you can change the authentication provider an application uses, you can not change the Zone that it is in.

Here is an image of the Authentication Provider listing. Notice this application is in the Internet zone, and the provider is Windows.

image

If I were to edit this application’s settings, I could change the provider, but NOT the zone.  In essence, there isn’t an easy fix.  :)

image


Resolution

There are various resolutions to this problem, but in a true consultative manner… it depends (what port you need the app running on, etc…)  The end goal is this:  You need an Authentication Provider for the Default Zone!!!

Possible scenarios:

  1. Scenario: You just need the zone
    1. Extend the application using the Default zone
    2. Remove SharePoint from the erroneous configured app, deleting the app in IIS
  2. Scenario: You are okay with just starting over
    1. Delete the application without deleting content database
    2. Recreate the application and add content database to the app (via stsadm)
  3. Scenario: Your erroneous app is on a port it must run on (firewall rules configured, etc…)
    1. Extend the application to a temp app on a non-utilized port (i.e.: 8484)
    2. Remove SharePoint from the erroneous configured app, deleting the app in IIS
    3. Extend the application again to the Port that you need (i.e.: 80)
    4. Remove SharePoint from the temp app, deleting the app in IIS


My 2 Cents
Personally, I think that SharePoint should handle these errors better.  If an authentication provider for the default zone is truly necessary for this code to execute:

  1. Don’t let the user remove SharePoint from an IIS Website if that site is configured for the Default zone
  2. Let me change the Zone for the application when changing the Authentication Provider
 
Share It:          
 
 

Links to this post

Comments

Mark  commented on  Tuesday, August 11, 2009  10:54 AM 

Oh thank you for this post. This has been KILLING me for about 4 days now.

This is one of the first apps I set up, and am getting these exact errors when I try to break inheritance on subsites or add web parts. IIRC, I think I did exactly the scenario you describe above, and didn't have an authentication provider in the default zone.

Thank you thank you thank you. You just saved my sanity (what little is left after working with SharePoint for a year or so now).

Dan  commented on  Thursday, August 13, 2009  5:23 PM 

Hey Mark,

Glad the post helped. Ya, it drove me a little bonkers as well.

Best,

Jeff  commented on  Thursday, September 10, 2009  2:00 PM 

Thank you. I have been working on this problem for two days.

michael  commented on  Monday, October 19, 2009  7:33 PM 

you are officially my hero
thanks!

Jill  commented on  Tuesday, December 01, 2009  5:18 PM 

I am going bald working on this same issue, but your resolutions are not appropriate for my situation. I have three entries for a specific web app in AAM; Default, Custom and an Extranet zone. When I look at the Authentication Providers for this web application there is only one entry listed ... the Default zone and the Membership Provider Name is Windows. I did try doing a full backup of the web app from our production server to a clean restore on a vm test server. I still get the exact same errors on the test server with only one zone (Default). If you could provide any suggestions on how to resolve this for our situation (before I have no hair left), that would be greatly appreciated. Our actual error is as follows:

Object reference not set to an instance of an object. at Microsoft.SharePoint.SPRoleDefinitionCollection.Init()
at Microsoft.SharePoint.SPRoleDefinitionCollection.get_Count()
at Microsoft.SharePoint.SPRoleDefinitionCollection.GetByIdNoThrow(Int32 id)
at Microsoft.SharePoint.SPRoleAssignmentCollection.Init()
at Microsoft.SharePoint.SPRoleAssignmentCollection.Undirty()
at Microsoft.SharePoint.SPRoleAssignmentCollection.get_Count()
at Microsoft.SharePoint.ApplicationPages.UserRoles.ListUsers(String sortExpression)
at Microsoft.SharePoint.ApplicationPages.UserRolesDataSource.ListUsers(String sortExpression)

Oksana  commented on  Sunday, January 24, 2010  3:26 PM 

Your post saved my sanity as well! The funny thing is that the faulty configuration was done with a help of a consultant that helped us "extend" our application to SSL. And I share your frustration about how SharePoint handles the default zone (as well as error messages).

Shay  commented on  Wednesday, June 23, 2010  10:46 AM 

Thanks a lot.
Saved me a lot of pain.

I just extended the web application, giving it a temp port/host header and BANG - everything's back to work !!

Leave a comment





CAPTCHA Image Validation