I’ve been battling this error several times over the past few weeks in varying contexts.  Today’s occurrence was in accessing "Page Settings" of a MOSS Page.  Thanks to YongYS for the following fix:

http://www.bronios.com/index.php/2008/01/18/moss-page-setting-error-value-does-not-fall-within-the-expected-range/

A few weeks ago I was running into this issue after backing up a content database and moving it to another farm.   Thanks to Stefan Gossner to pointing out the error in my ways:

http://blogs.technet.com/stefan_gossner/archive/2008/03/12/common-error-situation-with-when-using-backup-restore-to-transfer-a-database-to-a-new-farm-on-moss-2007.aspx

I have this nagging feeling that I have been down this road before, so I need to blog it so maybe, just maybe, I won’t waste another hour troubleshooting something I’ve done before.

Scenario:

You browse to Central Admin, or any Site Collection really, and you are prompted incessantly for  your user credentials.  After about 5-8 times, the page comes up.  You are NOT presented with a Forbidden message.

You check your IIS log files, and you see several 401 errors for WebResource.axd.

You remember something about installing SP2 when IIS wasn’t on the box, then installing IIS from a source that did not have the Service Pack slipstreamed.  Hmmm.  Might be relevant.

Solution:

Explained thoroughly by Paul Culmsee on his blog www.cleverworkarounds.com, http://www.cleverworkarounds.com/2007/11/15/darn-iis-and-service-packs/.  If it wasn’t foreshadowed by the last sentence of the Scenario, reinstalling Windows Server 2003 SP2 was the solution.

In the past week I have implemented several custom workflows for a client using SharePoint Designer.  The workflows were pretty simple:  A Forms Services form would be completed, in the form would be a the Manager’s name and e-mail address.  The workflow would use the "Collect Data" action to perform an approval workflow, assigning an item to the manager specified in the form.  Trouble was, the manager would receive the task notification, click the link in the e-mail to edit the task item, and receive an access denied error.

For the purposes of troubleshooting I opened the permissions on the task list as much as possible, granting nt authority\all authenticated users the Full Control permission.  Still the users received "Access denied".  Then, I found the following forum thread:

http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=1838253&SiteID=17

The solution wound up being a combination of two posts, this was by "Vansen":

I opened up the Site using the Sharepoint Designer. Then i right-clicked the workflows folder and chose properties. In the Security Tab i clicked the link "Manage Permissions using the browser". Then a new Browser window opened and i was able to adjust the rights for the Workflow Folder. In my case the rights inheritance was broken. I restored it and it worked.

And this one by "Andre Rentes":

I found a solution but not is the better…

-> Open Sharepoint Designer,

-> right click on Workflow 1 (My workflow)

-> select Publish Selected Files…

-> choose  File System and write a location ( c:\ ) for example

-> Click OK

 

Combining these two solutions fixed all three of the problematic workflows!  Thanks guys!

I have taken over maintenance of other people’s code in the past, and its generally a mixed-bag. Sometimes you inherit a plate of spaghetti, sometimes you luck-out and actually get a well architected and implemented codebase. The real payoff when inheriting maintenance though, is to read the fantastic comments left behind, such as this gem I unearthed today:

// if it’s a number we should sort it descending because it is probably a date
// bad? no, this is AWESOME!!!! Regular expressions are for assholes.
int.Parse(f.SubFolders[0].Name);
dv2 = this.GetFolderViewSorted(f, “DESC”);

Had an issue today where a developer was testing a web part that required a user profile, and an exception was being thrown that the user profile did not exist.  We verified in the SSP that the user profile indeed existed, and also used the "stsadm -o sync" command to force a profile synchronization.  However, we discovered that SharePoint was not seeing the actual user name that the user was logged in as, instead SharePoint saw it as "SHAREPOINT\System".  This led us to the following forum thread:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1195418&SiteID=1

What ended up being the issue is that the developer had configured the SharePoint application pool to run as the same identity that he was logging into SharePoint as.  We changed the configured identity in Central Admin -> Operations -> Service Accounts to use Network Service instead and the issue was resolved.