The other day I went to deploy a solution to our SharePoint farm and got the following error in the Solution Management in Central Administration.  Some important background info is that this solution first created a Web Application.

We have a 4 server farm and the solution wasn’t deploying to any of the servers.  Looking at the event log, we had several different errors all containing the text (the event ID for all of them was 6398):

Error during encryption or decryption. System error code 997.
Error during encryption or decryption. System error code 0.
Error during encryption or decryption. System error code 122.

All of these were based on a time job provisioning something, either the web application or the solution, or come to find out, some of our search services were having errors starting.  The web application for this solution was being created on one of our servers, but failing on the other three (this was what was actually holding up the solution from being deployed).

After doing some searching everyone gave two options:

1. Recreate your SharePoint Configuration database…yeah right, this is going to be our VERY LAST attempt.

2. Run stsadm –o updatefarmcredentials (if you want to stop reading here, run this command first and it should fix the errors listed above…ONLY if this doesn’t work consider recreating your SharePoint Configuration database)

Neither one of these really seemed to make sense, we created all 4 servers in the farm from scratch, install SharePoint on all of them at the same time, created about 8 web applications that had all provisioned fine already, and never made any changes to user credentials (as some posts suggested).  Since the web application was being created fine on Server 1, we started looking at servers 2-4 as to what happened that would block a web application from being provisioned.  We couldn’t find anything.

Finally, we looked at Server 1.  This server had a timer job running with a different credentials than Servers 2 – 4.  Come to find out, when the install had been done, for some reason SharePoint was installed on Server 1 with one set of credentials and on Servers 2 – 4 with a complete different set of credentials.  After realizing this, we conceded to the fact that yes, user credentials are probably all messed up in our SharePoint Configuration database.  We ran the stsadm –o updatefarmcredentials command this morning and all of a sudden the web application could be created, search services started and solutions were able to be deployed.

I’m still baffled as to how our original 8 web applications were created and how solutions were properly deployed previously, but hey, at least everything is fixed now and set up properly.

Another SharePoint 2007 development post from the non developer, so feel free to offer any suggestions and comments around my code as I’m still learning.  I know, I should be doing this on SharePoint 2010.  Trust me, I’m trying to get us there.

Anyways, a brief background on what I’m trying to accomplish. I’m working on a navigation solution for our current intranet that queries a list of SharePoint sites that have been requested, approved and created via our site request process.  The query results are then filter based on if the current user has access to the site.  This list contains variety of sites, site collections and sub-sites that are spread out across 3 different web applications.  The solution then displays those sites in a web part for users to have “quick access” to their collaboration sites.  It’s basically a way to provide navigation (contained in a web part) across site collections and web applications automatically off a list of sites.

In order to check for access I decided to use the DoesUserHavePermissions() function.  However, after writing this function:

private bool UserAccessToSite(String user, SPWeb testWeb, SPSite testSite){
    bool access = false;
    try{
        access = testWeb.DoesUserHavePermissions(user, SPBasePermissions.EmptyMask);
        return access;
    }
    catch{
        access = false;
        return access;
    }
}

I was getting the following error stating that the “List does not exist”

I tried a variety of different approaches just to get it to return false if the user has Access Denied to the site.  After a bunch of different tries and some searching online, I ran across this post by Krichie that solved the problem for me.

Right before checking DoesUserHavePermissions I had to add the line SPSite.CatchAccessDeneidExceptoin=false;

So, the final code that is now working is:

private bool UserAccessToSite(String user, SPWeb testWeb, SPSite testSite){
    bool access = false;
    try{
        testSite.CatchAccessDeniedException = false;
        access = testWeb.DoesUserHavePermissions(user, SPBasePermissions.EmptyMask);
        return access;
    }
    catch{
        access = false;
        return access;
    }
}

My web part is now configured in order to query the list and only return a link to a SharePoint site if the user currently logged into SharePoint has access to that site.  I still have some work to do on the web part and the rest of the solution, so as I continue this adventure I’ll try to post any other updates.  Who knows, maybe once I finish it I’ll even post the whole solution up here.

Again, feel free to correct my code or offer other suggestions as I continue to delve into the SharePoint development space.

Today I needed to do some testing around large lists, views, queries, etc as I’m working with a proposed feature.  I realize there is a lot of documentation around this in terms of keeping a view under 2000 items, or not having more than 2000 items in any folder.

These are recommendations that have been backed up with data, however, sometimes nothing beats just testing everything out for yourself.  How is my farm or this feature going to react when a list gets too large?

I found the SharePoint 2007 Test Data Population Tool that enables you to quickly load up your farm with test data.

MOSS – http://sptdatapop.codeplex.com/releases/view/1214

WSS – http://sptdatapop.codeplex.com/releases/view/1141

There are certain features that are available in WSS that aren’t in the MOSS version, so even if you have MOSS, you’ll probably want both.  This tool made in very easy for me to fill up a test list with as many items as I wanted with 3 short lines in an XML file and a simple command point to the XML file and the URL to the site containing the list.

There is a ton of additional functionality in these tools also as far as creating sites, site collections, load testing, etc. that I haven’t even begun to explore.  So, if you want to do some testing around what your SharePoint farm can handle, I would recommend adding this to your tool belt.  Just make sure you don’t run this against a production farm if you are testing the limits .

I had this problem today on one of our sites that has anonymous access enabled.  We wanted to link to some PDF files in our quick launch navigation, so, naturally, we logged into the site and manually added the links.

However, when we tested the site with anonymous access the links weren’t there! So, next step, check the document library.  It was inheriting permissions, and I could even manually type in the URL to the document library and the PDFs using anonymous access and view everything just fine.

So, time to start digging.  Fortunately I found a thread on a discussion board that pointed me here – http://support.microsoft.com/kb/927082/en-us?spid=11373&sid=200.  Apparently when you turn on Anonymous access, Microsoft doesn’t think you could really want everything to be anonymous access.  Anywho…I figured it was worth a shot, so I logged into the server, disabled the feature running the command in the KB article linked above, turned anonymous access off and back on and what do you know.  It worked!!!

So, if you are having any trouble with certain lists, documents, navigation, etc.  Give this solution a shot.  As of yet I’m not aware of negative impacts to disabling this feature, but if I find any I’ll definitely update this post.

I’ve actually done it, a SharePoint Administrator writing a web part.  Granted this web part is in it’s earliest stages, but it performs the task I needed it to.

So, what does it do? It’s a very simple SharePoint 2007 web part (So far I have only tested it on MOSS 2007 Standard Edition) that takes a URL (must be absolute at this point in time) and the name of a SharePoint Calendar list and displays the events on the calendar for the given week.  It can be placed on any page or site within your web application and query a calendar on any other site.

Also, the key issue that got me writing this web part is that is correctly handles recurring appointments on your SharePoint calendar.  If you have recurring appointments, this web part will show the correct start and end time for ONLY the recurring event in the current week rather than the end date for the last recurring appointment.  Here is a screen shot displaying the web part returning a variety of different events scheduled in the same week.

Granted, it’s nothing fancy, but for me it was a big deal coming from a SharePoint Administrator background.  There are also lots of bugs to it and errors that aren’t properly handled.  But, it’s a start.

If you want to play with the web part, you can download the solution file below.  Just remember, it’s free, it’s my first real web part and there are definitely several bugs.  So, if you choose to try it out:

1.  Don’t complain about it not working the way you want or about bugs…remember it’s FREE. 

2.  If you do find a bug or have suggestions to improve it, I welcome the comments and suggests and we’ll see what I can do as time allows.

3.  There is no warranty, guarantee, etc, etc…pretty much, I’m providing it free as is.  If you choose to install it in your farm that is your choice and your responsibility.  By downloading this web part you are agreeing not to hold me responsible for any negative effect or impact it has on your SharePoint environment.  Again, if it does something weird, feel free to let me know and I’ll do my best to help you, but there are no guarantees.

If you still choose to try the web part you can download it here.  To install and use the web part:

1.  Download the .wsp file

2.  Add the solution to your farm

3.  Deploy the solution

4.  Activate the Site Collection Feature “Upcoming Events Web Part”

5.  Add the web part to your page

6.  Open the Web Part Properties and in the respective boxes enter an Absolute URL for the page where your Calendar List is located as well as the Calendar Name.

7.  Click OK.

***Update: Today Microsoft is releasing as out-of-band security update to address this issues.

- SharePoint Team Blog Announcement – http://blogs.msdn.com/b/sharepoint/

I’m sure by now all of you have heard about the ASP.NET security vulnerability and there are plenty of references out there about it and how to fix it so I’m not going to go into much detail here.  The key point is yes, it effects WSS 2.0, SharePoint 2007 (WSS 3.0 and MOSS) and SharePoint 2010 (Foundation and Server).

The best references I have found so far, and I will refer you to rather than writing it all up myself are":

1. The Microsoft SharePoint Team Blog, this is where the fixes are documented that you can put in place until a patch is released.

2. Scott Guthrie’s Blog, this contains a very good list of FAQs about the vulnerability.

If you’re like us, chances are you have users accessing SharePoint from several different browsers.  SharePoint 2007 can bring about many challenges for users not wanting to Internet Explorer, one of which is replying to threads in a SharePoint Discussion board.

To be perfectly honest I’ve never been a huge fan of the discussion board in SharePoint, so I haven’t often paid much attention to it.  However, since switching jobs, I have found the users here love the discussion board.  The first thing I did to make it even better for users, was to download the Quest Discussion board web part, to give users a much nicer interface for viewing posts.

Recently, more and more of our users have been accessing discussion boards from a browser other than IE.  When replying to a discussion, this brings up and ugly mess of HTML for the end users if they are replying from FireFox, Safari or Chrome.

We had three options for solving this:

1. Training – Make sure all users know that when replying to a discussion, they are not to touch the HTML, but simply add their response above it.  Feasible…but definitely not the best idea.

2. Require all users to use IE – hahaha…yeah right! Parts of our environment are accessible to our users from home as well as a subset of our users having the ability to choose if they want a MAC or a PC.  This just won’t happen.

3. Find a way for users to edit rich test (eliminating the HTML) when responding to or posting a new item in a discussion board.

Thanks to Telerik, we were able to take approach #3.  The Telerik RadEditor Lite (bottom of the page) provides two features.  One feature to use the RadEditor for Rich Text fields when using a browser other than IE and the second feature to use the RAdEditor for IE as well.  After adding and deploying the solution to the SharePoint farm and activating the feature on your SharePoint site, when you edit a Rich Text field from a browser other than IE, instead of the ugly html you are given a nice, easy to use Rich Text field from Telerik.

This is starting to get dangerous…I’m blogging about SharePoint development twice in a row.  Again, this may be something very basic to most SharePoint developers, but as I learn, I enjoy blogging about issues I’ve discovered and things I’ve learned as I continue to develop more.

My next venture into SharePoint development is to create some custom .ASPX forms for use within our SharePoint environment.  For our situation, InfoPath Forms Services would make much more sense, unfortunately, we only have SharePoint 2007 Standard with no plans to go to Enterprise.

So, I created a very basic .ASPX file with an equally as simple .cs (code behind file), packaged it all up as solution and deployed it.  However, when I went to access the site, I encounter a “Could Not Load Type…” error.  After a quick search on Google, I found – http://blogs.catapultsystems.com/matthew/archive/2007/12/07/could-not-load-type-error.aspx between that post and the post by Andrew Connell that was referenced there I was able to solve my problem.

When I had created my .aspx file I had failed to use the “5 part name” to reference the assembly file.  I had put Inherits=”NewForm.NewForm” rather than Inherits=”NewForm.NewForm, NewForm, Version=1.0.0.0, Culture=neutral, PublicKeyToken=*********”

As soon as I changed my .aspx file to use the 5 part name and redeployed my solution everything worked perfectly!

We have been having an issue with our search indexing and crawling in one of our SharePoint farms.  The problem is that after an undetermined set of time, pretty much all search queries wind up returning several results that show nothing but an IE icon.  The result isn’t attached or any page or give any textual information.  Obviously best case would be to figure out what causes this error, but at this point in time we haven’t been able to find the problem.

However, what we have discovered is that simply resetting the search index and running a full crawl will solve the issue.

So…until we can solve the issues, I wrote a small SharePoint timer job that simply resets our search index right before a scheduled full crawl runs.  I used Andrew Connell’s post (http://www.andrewconnell.com/blog/articles/CreatingCustomSharePointTimerJobs.aspx) to develop the Timer Job, Solution and Feature and modified it and was able to find the following code on http://www.sharepointdev.net/sharepoint–development-programming/programmatically-reset-all-crawled-content-41959.shtml that I inserted into the timer job frame work in order to automatically reset our index on a regular schedule to minimize the risk of our search issue effecting the end users.

try
{
    SearchContext sc = SearchContext.GetContext(ServerContext.Default);
    sc.Reset(true);
}
catch (Exception ex)
{
    throw new InvalidOperationException("Unable to reset content index.", ex);
}

For some of you, this may not seem like much, but coming from the SharePoint Administration/Configuration side of SharePoint and having very little real development experience I was rather proud of myself.

The other day I had an annoying problem accessing SharePoint sites.  I am running Windows 7, IE8 and Office 2007 and Office 2010 Beta.

Any internal SharePoint site continued to throw the error of element not found for init.js

It only happened on my desktop (my laptop worked just fine).  I tried clearing the temporary internet files, browser cache, even uninstalling and reinstalling IE8.

Nothing worked, I finally found the solution here – http://social.technet.microsoft.com/Forums/en-US/sharepointgeneral/thread/41e1874f-7825-4bfe-ba4c-37255d198df2

So, I opened up SharePoint Designer 2007, ran the diagnostic tool in the Help menu, restarted IE and everything was back to working as normal.