What I learned this week about Silverlight and Telerik’s RadEditor

Well, isn’t that special…

Just a quick note: If you are installing Telerik’s RadEditor and you get an error saying that Silverlight cannot be found, that is because you must download the 2.0 runtime on your server for the RadEditor to function correctly. Something to remember – I must write this down someplace…

SharePoint Development Training

Good SharePoint training can be hard to find – and it can be expensive. Harder yet is convincing your boss that you need time off and travel expenses to go away for a week.

If you live in (or can get to) Houston in March, however, I may have some good news for you. One of my favorite SharePoint bloggers, Rafael Perez (http://blog.rafelo.com) is putting together one of his famous weekend crash courses in SharePoint Development.

This course provides an in-depth look at everything from basic Content Deployment to full Feature and Solution generation for Windows SharePoint Server and Microsoft Office SharePoint Server. The class is strictly “BYOL” – Bring Your Own Laptop, and runs two full weekend days long (March 21-22, 2009).

Best part is – you don’t go home empty handed. You get to keep a hard disk with trial versions of software loaded and the work you built in class, all for $500.

Not a bad deal, overall… Check it out here.

Changing the Scope of the Telerik RadEditor Features

Telerik provides the RadEditor for MOSS in a Solution package (*.wsp). This solution contains two Features, which are scoped to be installed at the Web level of a SharePoint farm.

While this type of installation is quite functional, it means that every time a Site (Web in the Object Model) or Site Collection (Site in the Object Model) is created, its administrator would need to remember to activate the solution.

The Telerik website specifies a workaround for this shows you how to modify the two Telerik Features (RadEditorFeatureRichHtml and RadEditorFeatureRichText) by doing the following:

1. Turning off the Features
2. Altering the Feature Scope for each in the Feature.xml file
3. Turning the Features back on

While this works fine, these steps did not meet my requirements - if the Solution that created the Features is reinstalled or modified, the feature.xml for each would be overwritten from the contents of the Solution. This would revert the scope back to Web instead of Site, which is not acceptable.

I specifically wanted to make this change more permanent such that it could survive the reinstallation of the solution (by the way, this works with the trial version of RadEditor). The only alternative was to modify the solution. To do so:

a. Make an archival copy of the original solution from Telerik. This document assumes that the copy is NOT named RadEditorMOSS.wsp.

b. Rename the RadEditorMOSS.wsp file to RadEditorMOSS.cab.

c. Open the RadEditorMOSS.cab file using WinZip (Not the built-in Windows Unzip). If you choose to use the builtin Windows Unzip, this process will not work because (a) the file structure will be gone and (b) the feature.xml for one of the two features will overwrite the other.

d. Choose to extract all files to a location of your choosing. For illustration’s sake, we will choose the location as C:\Downloads\Telerik\RadEditorMOSS_5_3_2\RadEditorMOSS.

e. Open the RadEditorMOSS directory and then open the RadEditorFeatureRichHtml directory. In it, you will see one Feature.xml file.

f. Open it in an editor of your choosing (VS2005/2008, Notepad++, etc.) - Don't use NotePad, it may leave artifacts and hidden characters in the file.

g. Find the Line that reads 'Scope="Web"' and change it to read 'Scope="Site"'.

h. Repeat steps e-g for the RadEditorFeatureRichText directory.

i. IMPORTANT - These files need to be reassembled back into a CAB file, but you cannot use WinZip for this task. If you do so, all will be well until you try and install the solution, at which time you will get an error that reads "Failed to extract the cab file in the solution".

j. Download and install the cabdsk.exe utility (to c:\Program Files\Cabdsk) from the Microsoft Cabinet Software Development Kit (see http://support.microsoft.com/kb/310618 and http://kopperla.blogspot.com/2008/10/how-to-replace-files-in-sharepoint.html).

k. Open a command prompt and navigate to the c:\Program Files\Cabdsk directory.

l. Issue the following command: cabarc n RadEditorMOSS.cab C:\Downloads\Telerik\RadEditorMOSS_5_3_2\RadEditorMOSS\*.*.

m. Issue the following command: cabarc -r -p -P downloads\telerik\RadEditorMOSS_5_3_2\RadEditorMOSS n RadEditorMOSS.wsp c:\downloads\telerik\RadEditorMOSS_5_3_2\RadEditorMOSS\*.*.

n. Copy the finished RadEditorMOSS.wsp file from c:\Program Files\Cabdsk to c:\download\telerik\RadEditorMOSS_5_3_2\.

o. Delete the C:\Downloads\Telerik\RadEditorMOSS_5_3_2\RadEditorMOSS directory that was created by unzipping the original file.

At this point, you can simply follow the instructions for activating the Solution and Features (at the Site Collection) as shown on the Telerik web site.

Getting AJAX 1.0-dependent items to function in an AJAX 3.5 environment

This last week I was tasked with installing the RadControls for ASP.NET AJAX from Telerik into a SharePoint environment. In particular, the desire was to integrate the fully functional version of RadEditor for SharePoint with a publishing environment.

I spent quite a bit of time reviewing the documentation for this product, and what I figured out pretty quick was that while the majority of this product runs under AJAX 3.5 (part of ASP.NET 3.5 Service Pack 1), the RadEditor control uses the legacy AJAX 1.0 functionality.

So, what to do next? I looked at the instructions for each and found that I could install both AJAX 1.0 and 3.5 on the same machine (although that really did not seem reasonable). Then I realized that both would require modification to the web.config for my SharePoint web app; the modifications would overlap, however, and I was pretty sure that this would not work.

Not being that familiar with AJAX, I did a little checking. AJAX 3.5 provides backward compatibility with AJAX 1.0 - so far so good. Next, the question was how to cause this to work in the web.config for my web application.

I started by adding the web.config modifications for ASP.NET 3.5 found in the Telerik installation instructions.

Next, I found out how to offer AJAX backward compatibility in a web.config from a post on the Telerik forums here. Basically, what this addition does is build a dependency entry that redirects AJAX controls to use the 3.5 AJAX. To set this up:

In the <runtime>/<assemblyBinding> section of the web.config, add the following entries:

<dependentAssembly>
  <assemblyIdentity name="System.Web.Extensions" publicKeyToken="31bf3856ad364e35" culture="neutral" />
  <bindingRedirect oldVersion="1.0.61025.0" newVersion="3.5.0.0" />
</dependentAssembly>

This last section should be all you need to allow the backward compatibility for any AJAX 1.0 functionality.

Pointers:

• Make backup copies of your web.config file before making any modifications.
• Make sure that if you are cutting and pasting this text in that no hidden characters are copied. Hidden characters will cause the web app not to function after the web application is reset.
• Don’t forget to reset the web application to allow these web.config modifications to take effect.

SQL Collation and SharePoint 2007

I will not forget to write this down... Latin1_General_CI_AS_KS_WS

I will not forget to write this down... Latin1_General_CI_AS_KS_WS

Now what was it I needed to write again?

Oh Yeah, I Remember...

Every time I build a SharePoint Farm, be it WSS 3.0- or MOSS 2007-based, I always forget the collation setting for SQL databases being used for SharePoint. There are several places on the web that this information is posted, yet I can never seem to find it in a hurry.

Here is the proper SQL collation for a WSS/MOSS installation:

• Latin1_General Character Set
• Case Insensitive - A and a are treated as the same character
• Accent Sensitive - a and á are NOT treated as the same character
• Kana Sensitive - Japanese Hirakana and Katakana characters which look the same are NOT treated as the same character
• Width Sensitive - Single-Byte and Double-Byte versions of the same character are NOT treated as the same character

What effect does this have in my SharePoint Farm?

Although I do not (yet) know all of the items an improperly selected collation can affect, here is what I do know:

1. Search relies on collation when crawling information in a SharePoint site.
2. There have been reports of improperly configured collation which result in inconsistent behavior such as services not starting correctly.

So what, I can always change it later, right?

Yes, but I can almost guarantee you won't like it - the main databases in a SQL instance reflect the chosen collation. So, in order to change the collation for an instance that will be used for SharePoint, you have to change it on those databases as well.

This involves:

• Backing up the databases
• Documenting all user accounts/permissions
• Dropping the content databases
• Rebuilding the MASTER database
• Restoring the content databases
• Recreating the logins

In short, set this up right before you build your SharePoint Farm. If you are installing SharePoint against an existing SQL backend, consider placing it in its own SQL instance.

Sources

There is a good Blog Entry about it by Areej Abukar on the Jordan SharePoint User Group Blog. Gotta love the Internet.

More detailed information about SQL collation can be found here.

Introduction

Hi!

My name is Troy Lanphier, and I am a SharePoint Architect working in Houston, Texas. I have been building SharePoint solutions for almost 5 years now (since the end of SPS2003 beta 2).

My prior experience includes a large amount of infrastructure work in:

• Storage Area Networks (HP/Compaq and Dell, primarily)
• Server Infrastructure and Integration
• Disaster Recovery
• End User and Systems Administration Training

Why a Cookbook?

Well, quite honestly, as much for me as for the folks reading this Blog. I write a lot of documentation about the SharePoint environments I implement, but this is very specific in nature, tailored for the particular customers I work for.

In a word, Recipes - I wanted a place that I can look up the items I find myself doing over and over for different customers; things like automatically registering iFilters for Search, configuring LDAP filters for User Profile Imports, and so on. In addition, from time to time, I may discuss overall architectural strategies for SharePoint installations which I have implemented (no clients named, however) and will document the pros and cons of how I built these environments.

Before You Run Off...

Note that the Recipes found in this site may have been originally crafted for specific clients. I will try and make sure that items such as scripts, etc. are cleaned up as much as possible to make them generic, but the responsibility ultimately falls to you, the reader, to ensure that you test all solutions thoroughly in a Development or Test environment before deploying to your Production environment.

I hope that you will find this useful, and I will try to update this site regularly. Thank you for your attention. - Troy Lanphier