Ben There, Done That

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.

Have you ever had a long SharePoint list that you wanted paged by the first letter of a column rather than by simply picking the number of items you wanted on each page?

That’s exactly what I ran into the other day.  I had a list just short of 3000 medications that medical staff at work needs to reference.  They needed the list to be sorted alphabetically and be able to quickly jump to the various medications based on the first letter of the medication name.

After doing some searching I found this post that solved the issues and performed exactly as I was hoping – http://mdasblog.wordpress.com/2009/06/19/alpha-selection-of-list-items/

Additionally, here is a tutorial video that was posted in the comments of the blog posting that was very helpful.

As discovered by Todd Carter there is a memory leak in SharePoint 2007.  He has outlined the details as well as a work around to the fix the memory leak.

I decided to do some testing with it, however, when I compiled the dll, placed it into the GAC, and changed my global.asax file, I started getting this error: “Could not load file or assembly ‘[Assembly Name]’ or one of its dependencies.  The system cannot find the file specified.”

After digging into this error for a while I discovered my problem.  This may be fairly obvious to developers out there , but coming at this from more of a SharePoint administrator type roll, I missed this one step that isn’t outlined in the steps provided by Todd.

After deploying your dll to the GAC, you need to open up your web.config and place

<add assembly="[Assembly Name], Version=[Version Number], Culture=neutral, PublicKeyToken=[Public Key Token]" />

in the web.config file of the web application you wish to apply your fix to.  This line should be added between <assemblies> and </assemblies> in the web.config file.

All of the information: Assembly Name, Version Number and the Public Key Token can be found by right clicking on your dll in the GAC and viewing the properties of the dll.

Once I added the assembly to my web.config for the web applications I was trying to apply the fix to, everything worked as expected.

I was working with SharePoint surveys the other day and discovered an old issue working with surveys and Microsoft Office that appears to have resurfaced.

We were trying to see what other reports we could generate from a SharePoint survey.  Naturally with the option to export to Excel, we figured why not just export all the survey data into Excel and play with it there.  To test it out I tried to get a variety of questions in the survey, one of these questions being the rating (matrix) survey question.

I created a few responses to the survey and attempted to export the list data to Excel (I’m running 2010 Beta).  Everything came over well with the exception of the matrix type questions.  I did some searching and this was also an issue with Excel 2003.  However, people said it was resolved with Excel 2007.  I installed Excel 2007 and sure enough the matrix questions imported into Excel 2007 just fine.  I tried Excel 2010 once more and the values still failed to come over.

So, it appears that the problem with importing matrix type of questions from SharePoint 2007 to Excel 2003 has returned in Excel 2010.  Granted, this is the beta, so maybe it will be fixed by the release.

I also want to do some testing with SharePoint 2010 surveys, Excel 2010 and possibly PowerPivot.  I’ve been reading some great things about PowerPivot but haven’t had much of a chance to play with it for myself.  Once I get a chance to do some testing with these tools I’ll write a new post.  Hopefully there will be some good news about doing more in depth analysis of SharePoint Survey results using these new tools.

SharePoint is designed to security trim your search results based on your user ID, a great feature to have in SharePoint as you don’t want search to return results of pages and content a user doesn’t have access too.  However, this requires one extra “step” at times when moving a site from development to testing or even to production.

I’m sure this topic has been blogged about before as this isn’t the first time I’ve run into it, but I figured I would write a short post about it for anyone that encounters what would appear to be an issue with their Search in SharePoint.

The scenario: You have been building out a SharePoint site and you are ready to release it to the rest of your users. You have tested everything using your own credentials.  You add a new user to the site with credentials equivalent to your end users and start testing with those credentials before going live.  Everything is working as expected…until

The problem: Your perform a search…You go to your search page, search for some well known content that you know should be returned, but you get no results in SharePoint search.  Your navigate to the page and you have access to it and can view the content you are searching for.  To further test, you run a few more searches, but everything comes back with no search results.

The resolution: When SharePoint performs a crawl (incremental or full) it looks at all your content AS WELL AS who has permission to access the content.  If you add users to your site, and immediately try a search before running a search crawl, the search index still has that the newly added user doesn’t have access to the content.  So, if you are going to add new users to the site that need access to search, or you are going to be testing search, immediately after adding those new users, run an incremental crawl so your SharePoint search index can pick up that these new users actually have access to the content you are searching for.

After installing Office 2010 on my computer (both laptop and desktop) running Windows 7 RTM, I had a problem opening any Office files stored in our SharePoint 2007 environment.  I would click on a file to open it or edit it, the Office 2010 application would open, however, the file wouldn’t open.

I could download the document to my desktop, open it, edit it, and re-uploaded it, but this fare far from ideal.  I could link the site to Colligo, but I don’t want to have connect to a site every time I want to open a document.

Finally, today I ran across this helpful string of comments on the TechNet forum – http://social.technet.microsoft.com/Forums/en-US/office2010general/thread/230fc30a-8922-4c75-a8fc-540b0282dff8

In short, the solution is to make a fake proxy in IE:

1. Open up Internet Explorer
2. Click Tools –> Internet Options
3. Click the Connections tab
4. Click LAN settings
5. Check “Use a proxy server for your LAN (These settings will not apply to dial-up or VPN connections).”
6. Enter 127.0.0.1 for the address
7. Click Advanced
8. In the Exceptions type: *.*
9. Click OK, OK and OK

You should now be able to browse to a SharePoint site, click an Office document and have it successfully open in your Office 2010 client.  This successfully worked for me with MOSS and reports in the TechNet forum are that it works with WSSv3 as well.

Just this morning, I was working with a client who had some errors pop up in their SharePoint farm.  I looked at the Windows Event log and didn’t find a whole lot of helpful info.  So, I moved on to the ULS logs, to my dismay, they were almost all 0 KB with a couple of files that were 2 KB or 3 KB.

I opened up the files that appeared to have some text in them and found the following entry:

“08/20/2009 10:38:58.08     wsstracing.exe (0x07A0)                     0x07CC    ULS Logging                       Unified Logging Service           uls1    Monitorable    Tracing Service lost trace events.  Current value 5.”

Naturally I went to Google with my error as I had never seen this before and found this blog post: http://weblogs.asp.net/jimjackson/archive/2008/05/13/sharepoint-logs-tacing-service-lost-trace-events.aspx by Jim Jackson.  I restarted the Windows SharePoint Services Tracing service just as he suggested and bingo! My ULS logs started recording events again.  Thanks Jim!