Just a short, simple blog for Bob to share his thoughts.
31 May 2011 • by Bob • SharePoint
Sometime last year I wanted to set up a SharePoint 2007 website for my family members to exchange information. That being said, I was using a custom membership provider, and I ran into a few issues while I was setting things up. I had kept detailed notes while I was configuring my server and troubleshooting the problems that I encountered, and with that in mind, I thought that I would share my experiences. ;-]
My web server is only an older 32-bit Windows Server 2008 computer, so I couldn't install SharePoint 2010 (which is 64-bit only) and I had to install SharePoint 2007. Taking that into account, there were a few additional considerations that I had for my environment:
With my specific considerations in mind, I took a look at the following article to get started:
That being said, I did not use the following articles, even though they are related to my scenario and they looked interesting:
Here are the brief details on how I created my SharePoint website:
<Users> <User> <UserName>Alice</UserName> <Password>P@ssw0rd</Password> <EMail>alice@contoso.com</EMail> <Roles>Admins</Roles> </User> <User> <UserName>Bob</UserName> <Password>P@ssw0rd</Password> <EMail>bob@contoso.com</EMail> <Roles>Authors</Roles> </User> </Users>
There are a few additions that you have to make to your website's web.config file, as well as the SharePoint Central Administration web.config file for SharePoint 2007:
<system.web>
section of your website's web.config; in my example that file would be located at "C:\Inetpub\SharePointSite\wwwroot\web.config":
<!-- added on 05/31/2011 --> <membership defaultProvider="ReadOnlyXmlMembershipProvider"> <providers> <add name="ReadOnlyXmlMembershipProvider" type="ReadOnlyXmlMembershipProvider, ReadOnlyXmlMembershipProvider, Version=1.0.0.0, Culture=neutral, PublicKeyToken=426f62526f636b73" description="Read-only XML membership provider" xmlFileName="~/App_Data/MyUsers.xml" /> </providers> </membership> <roleManager enabled="true" defaultProvider="ReadOnlyXmlRoleProvider"> <providers> <add name="ReadOnlyXmlRoleProvider" type="ReadOnlyXmlRoleProvider, ReadOnlyXmlRoleProvider, Version=1.0.0.0, Culture=neutral, PublicKeyToken=426f62526f636b73" description="Read-only XML role provider" xmlFileName="~/App_Data/MyUsers.xml" /> </providers> </roleManager> <!--/added on 05/31/2011 -->
<system.web>
section of your SharePoint Central Administration web.config file; on my server that file is located at "C:\inetpub\wwwroot\wss\VirtualDirectories\6087\web.config":
<!-- added on 05/31/2011 --> <membership defaultProvider="ReadOnlyXmlMembershipProvider"> <providers> <add name="ReadOnlyXmlMembershipProvider" type="ReadOnlyXmlMembershipProvider, ReadOnlyXmlMembershipProvider, Version=1.0.0.0, Culture=neutral, PublicKeyToken=426f62526f636b73" description="Read-only XML membership provider" xmlFileName="~/App_Data/MyUsers.xml" /> </providers> </membership> <!--/added on 05/31/2011 -->
SharePoint Central Administration needs to be able to find the MyUsers.xml file, so I created an App_Data folder under physical path of the SharePoint Central Administration website, and I added a symbolic link in that folder that pointed to the physical MyUsers.xml file. Here's how I did that:
cd C:\inetpub\wwwroot\wss\VirtualDirectories\6087
mklink MyUsers.xml C:\Inetpub\SharePointSite\wwwroot\App_Data\MyUsers.xml
Note: I could have copied the XML file, but I preferred to use the symbolic link instead of having to manage two copies of the file.
If you were installing a membership provider that can perform lookups, you could add an additional entry to your SharePoint Central Administration web.config file:
<PeoplePickerWildcards> <clear /> <add key="AspNetSqlMembershipProvider" value="%" /> <!-- added on 05/31/2011 --> <add key="ReadOnlyXmlMembershipProvider" value="%" /> <!--/added on 05/31/2011 --> </PeoplePickerWildcards>
Okay - I admit that I everything that I did so far was probably making things harder that they needed to be, but I love a good challenge. ;-]
That being said, I ran into some problems that I thought would be worth mentioning, just in case someone else ran into them.
When browsing to my SharePoint website, I received several HTTP 403 errors. I used Process Monitor to troubleshoot the problem, and I discovered that IUSR could not access the "bin" folder in my website. (I'm still not quite sure why it was trying.) To resolve these errors, I used the following steps:
cd C:\Inetpub\SharePointSite\wwwroot
icacls bin /grant IIS_IUSRS:r
In my situation the problem was for IUSR, but if you are using a different anonymous identity or your application pool is running as a unique identity then it might be a different user. In any case, Process Monitor will let you know who needs permissions.
Later I discovered the following blog post by John Powell:
In that blog, John suggests adding the following permissions for the "bin" folder:
icacls bin /grant users:r
I'm not sure if that's necessary, but it's worth pointing out.
When browsing to my SharePoint website, I received several HTTP 404.8 errors. Those errors mean that the built-in IIS 7 Request Filtering feature was blocking something, so I did the following:
</configuration>
tag:
<system.webServer> <!-- added on 05/31/2011 --> <security> <requestFiltering> <hiddenSegments> <clear /> <add segment="web.config" /> <add segment="bin" /> <add segment="App_code" /> <add segment="App_GlobalResources" /> <add segment="App_LocalResources" /> <add segment="App_WebReferences" /> <add segment="App_Data" /> <add segment="App_Browsers" /> </hiddenSegments> </requestFiltering> </security> <!--/added on 05/31/2011 --> </system.webServer>
Note: This removes all of the hidden segments from the global IIS 7 Request Filtering settings, which may be overkill. I have a lot of custom global request filtering settings, and I didn't want to go through each individual setting to see which setting was blocking files that I needed, so I used settings for my website that cleared the inherited request filtering settings and added the default settings.
When browsing to my SharePoint website, the information bar in Internet Explorer kept prompting me with the following message:
The Web site wants to run the following add-on: 'Name ActiveX Control' from 'Microsoft Corporation'. If you trust the Web site and the add-on and want to allow it to run, click here...
This message was highly frustrating, so I did some digging around the Internet and discovered that I could hack the INIT.JS file for SharePoint to suppress this message. Here's how I did that:
ProcessImn()
and ProcessImnMarkers()
functions, and I remarked out the contents. Here's what this looked like when I was done:
function ProcessImn() { // if (EnsureIMNControl() && IMNControlObj.PresenceEnabled) // { // imnElems=document.getElementsByName("imnmark"); // imnElemsCount=imnElems.length; // ProcessImnMarkers(); // } } function ProcessImnMarkers() { // for (i=0;i<imnMarkerBatchSize;++i) // { // if (imnCount==imnElemsCount) // return; // IMNRC(imnElems[imnCount].sip,imnElems[imnCount]); // imnCount++; // } // setTimeout("ProcessImnMarkers()",imnMarkerBatchDelay); }
I should note that this solution is unsupported; and a few months I hacked my INIT.JS file, Microsoft published the following Knowledge Base article with a couple of different methods:
That being said, I like my solution better. ;-]
Note: This blog was originally posted at http://blogs.msdn.com/robert_mcmurray/