Alternate Access Mapping Issue

Recently one of my clients started reporting that they were experiencing an intermittent issue where they would randomly receive a HTTP 500 response with the following error:-

[ArgumentOutOfRangeException: startIndex cannot be larger than length of string. Parameter name: startIndex]
System.String.InternalSubStringWithChecks(Int32 startIndex, Int32 length, Boolean fAlwaysCopy) +2916027
System.String.Substring(Int32 startIndex) +17
Microsoft.SharePoint.ApplicationRuntime.SPRequestModule.Log(HttpContext context, SPWeb spWeb, Int64 bytes, UInt32 version) +532
Microsoft.SharePoint.ApplicationRuntime.SPRequestModule.PostRequestExecuteHandler(Object oSender, EventArgs ea) +199
System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +92
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +64

When reflecting in to the Microsoft.SharePoint dll I could see this was occuring in some code to do with Url.

Looking in the event log on the SharePoint web front ends they were full with multiple copies of the following error:-

Invalid URL: http://www.abc123.com. You may also need to update any alternate access mappings referring to http://abc123.com. Help on this error: http://go.microsoft.com/fwlink/?LinkId=114854

In this environment there are two different hostnames for the SharePoint app (abc123.com and www.abc123.com in this blog post). I took a look at the Alternate Access Mappings and noticed there were two Alternate Accessing Mapping Collections set for the web application. I couldn't work out how this could happen until ServerFault.com helped me out :-)

So it turns out that an External Resource Mapping would cause this to occur.

This was not the case in this environment as I couldn't delete the AAM collection through the UI and running this command:-

stsadm -o deletezoneurl -urlzone Default -resourcename www.abc123.com

resulted in this error...

The IncomingUrl is not present in the collection

The environment was set up as follows:-

1 Web Application running as abc123.com
2 AAM Collections both with one entry for the Default zone (one with abc123.com and the other with www.abc123.com)
1 IIS Website with both hostnames mapped

I knew that this setup was not the standard way to setup two hostnames for one SharePoint Web App. Ideally, there would be one web app (abc123.com) extended to a different zone and assign www.abc123.com to the second zone.

So I carried out the following actions:-

1) Remove the www.abc123.com mapping from the IIS website through IIS Admin on all front end boxes.
2) Ran the following command to remove the AAM collection for www.abc123.com from SharePoint:-

stsadm -o deletezoneurl -urlzone Default -url www.abc123.com

3) Extend the original Web Application in SharePoint to a new zone with hostname www.abc123.com
4) Copied all custom settings from the original website web.config to the new extended website web.config.
5) Copied all custom dlls from the original website bin directory to the new website bin directory

I've got no idea how the system got in this state (before my time! ;-) ) but this stopped all the errors appearing in the event logs and there hasn't been a single complaint about the original problems since!

Hope this helps anyone else experiencing this issue :-)

Excel 2007 Files Automatically Open with Excel Web Access

When a user has 'Read' permissions or higher to an Excel 2007 workbook (.xlsx) within a SharePoint 2007 document library that they have only 'Limited Access' permissions to, something strange happens. :-)

In this situation, when they click on the file, instead of opening the workbook with Excel, SharePoint attempts to open the document with Excel Web Access. Disabling Excel Calculation Services on the server will not change this functionality! (only make it break further ;-) ).

The workaround is to either give the user 'Read' or higher permissions on the document library or to change the .xlsx file to a regular .xls (Excel 97 - 2003 workbook).

Let me know if you find a better solution! :-)

Document Library Limited Access - Access Denied

I'm sure this is well known, but I've just stumbled across this one...

When you give someone contribute access to a single document within a SharePoint 2007 document library they automatically get given 'Limited Access' permissions to the document library. This gives them view only access to the document library and when the visit the library they will only be able to see the documents that they have 'Read' or higher access to.

The issue is that if such a user tries to access the document library using a hyperlink like this...

http://server/sites/sitecollection/documentlibrary/

they will receive an 'Access is Denied' error message. The fix is to append 'Forms/AllItems.aspx' to the URL like this...

http://server/sites/sitecollection/documentlibrary/Forms/AllItems.aspx

Hope this helps someone out there :-)

SharePoint Search - Access is Denied - Myths Dispelled

Over the last couple of days I've been setting up Microsoft Office SharePoint Server 2007 Search on my development box and encountering some issues. I have a fairly straightforward setup running MOSS 2007, SQL 2008 and Windows Server 2008. I have been trying to set up a simple search of my environment so that my Site Collections are crawled and indexed.

I went through and set up the environment based on the principal of least privileges. Despite following setup procedures to the letter when I ran the Search crawl to create the index I found the following error in the crawl logs:-

Access is denied. Verify that either the Default Content Access Account has
access to this repository, or add a crawl rule to crawl this repository

This led me on an internet search with a number of false pointers to 'recommended' solutions on forums and blogs. Because of this, I spent a fair amount of time implementing these 'solutions' before finding the true issue.

So here are some of the myths I came across that are not needed:-


Myth #1 - The Default Content Access Account needs to be granted rights to the Site Collections

I gave the content access account full control through the SharePoint UI permissions screens. This did not solve the problem and is not required.


Myth #2 - The Default Content Access Account needs to be granted read rights to the content database

I opened SQL Server Management Studio and went to Server - Security - Logins - Content Access Account then viewed the properties of this account. I selected 'User Mapping' to view the access the account had to the content databases. The content access account had no direct permissions on the content databases and just had public access inherited from its permissions to the database in general.

It was recommended by a number of forum posters that the content access account needs explicit read permissions to the database. One poster goes as far as saying I should grant db_datareader, db_datawriter and db_ddladmin roles to the account. I did this and I still experienced the 'Access is Denied' error.

I can safely say that, given the same setup, you should NOT need to manually add any extra role permissions to the SQL content database for the content access account.


Myth #3 - Turn on the WSS Search service and associate content databases with the search service

In the Central Administration - Operations - Services on Server screen it shows that 'Office SharePoint Server Search' is started but 'Windows SharePoint Services Search' is stopped. At first I wondered if the MOSS Search had a dependancy on the WSS Search. So, as described in a blog post, I started the Windows SharePoint Services Search. I then went in to the Central Administration - Application Management - Content Databases screen. I clicked on the content database and associated the database with the WSS Search Service that I just started.

After this, I reran the crawl, but once again it failed with the 'Access is Denied' error.

There is NO dependancy between the 'Office SharePoint Server Search' and 'Windows SharePoint Services Search'. Also, you DON'T need to associate the 'Office SharePoint Server Search' service with the content databases in the Central Administration - Application Management - Content Databases screen.


Myth #4 - The Content Access Account needs to be the same account as the account running the Office SharePoint Server Search service

One blog post I found told me that the content access account must be the same as the account used to run the MOSS Search service. I tried changing the content access account to the account running the MOSS Search service. Once again, 'Access is Denied'.

There is NO need for the Content Access Account to be the same account as the MOSS Search service account.


So, with all those myths busted, what was the solution for the 'Access is Denied' error when crawling content databases?

In Windows Server 2003 SP1 a security hole was plugged. This stopped you accessing content on the local machine from the local machine using a host name thats mapped to the loopback IP address (127.0.0.1). As the indexer runs on the local machine in a development environment and crawls the content which is also hosted on the local machine access is blocked.

To get around the issue we can make an addition to the registry (read as: be careful!). This allows us to add exceptions to the rule or turn the rule off. We really don't want to turn off this rule as it is there for a good reason. So we want to apply Method #1 from this Microsoft knowledge base article on the subject:-

http://support.microsoft.com/kb/896861

As a word of warning though, I stumbled across a small issue when applying this. My web application's host name is intranet (so accessed using http://intranet/). So I added 'intranet' to the registry key, but I was still receiving the 'Access is Denied' error. I then realised that this was because 'intranet' was not the fully qualified domain name. I opened a command prompt and ran an nslookup on intranet which showed that the FQDN for this entry was intranet.domainName.local. Once I entered this in to the registry key, hey presto, no more 'Access is Denied'! Hurray!!! :-)

Special Mention: Many thanks to Andrew Woodward of http://www.21apps.com/ for his help!

View a SharePoint Blog Through a Web Part

When you create a blog in SharePoint it is created as a subsite (here's how). I had a request from a client to display the blog posts in a web part on the main site. After thinking about it for a bit I thought I'd just use the RSS Viewer web part to display the RSS feed from the blog. Unfortunately this resulted in the following message:-

"The RSS webpart does not support authenticated feeds"

After a bit of googling around it appears that this solution is not viable because we are using NTLM authentication. This prompted me to assess the alternative - moving to Kerberos authentication. On the face of it this seemed like a great idea. Posts were saying about how much faster Kerberos is and how much more secure it is along with how it was going to fix my issue. Then I looked at how to implement it, it's not a quick change. I also remember working with a SharePoint MVP a year or so ago who seemed very wary about moving from NTLM to Kerberos and the unintended side effects that may occur. So, I'll have a chat to our infrastructure team about moving to Kerberos at some later point in time, but it seems a bit overkill for this issue.

I had a bit of a think about the problem and my mind started thinking about creating a custom web part. I think, coming from an ASP.net development background, I'm always too hasty to look for the 'custom code' approach to these type of SharePoint issues. I said to myself that I'd try to find an out of the box way around this. That's when I remembered the Content Query Web Part.

The content query web part allows you to pull data from lists from sites within a site collection. It sounded like a perfect solution to my issue. People are always telling me how great it is (which makes me think I'm not using it anywhere near enough) so I gave it a try. I used the guidance provided by George in an ECM Team blog post. It wasn't a two click solution but it wasn't rocket science...

1. Create the web part and change the location to pull data from the posts list in the blog subsite.

2. Change the .webpart file to pull in the Body field.

3. Modify the ItemStyle.xsl in the style library to display the fields as required.Nice and simple but very effective. :-)

Let me know if you'd have thought about or tackled this differently.

Start of random mumblings...

Hi All,

Welcome to my first blog, so excuse me if I'm a bit rusty! Let me introduce myself. My name is Russell Giddings and I am a .Net Developer with a passion for SharePoint in particular. I have 7 years commercial experience of development although I've been playing around with code for over 20 years.

Anyway, enough about me, on to the blog. Firstly, I don't believe I am all knowing and all seeing. So this is definitely not going to be a preaching blog! I feel that given the pace of technology evolution there is always huge scope for learning and improvment. What I aim to gain from this blog is other peoples views and critiques on my processes and solutions. It's part of my journey to becoming a top class developer which may help others who are in a similar position. So get commenting and tell me what you really feel!!!

Maybe one day I'll be as capable as you! ;-)