So, the RadEditor solution is not scoped globally, meaning that after you install it, it is not used on users sites unless they activate it in their site settings. What is the way around this? The answer (big surprise) is STSADM.
We again use:
STSADM -o enumsites to collect all existing site URLs. We cleverly strip out the site URLs from the (I hate) XML output. We then save these URLs to a text file (one URL per line) and use this to feed a FOR loop on the CMD shell.
STSADM -o activatefeature -id 747755CD-D060-4663-961C-9B0CC43724E9 -url [site URL]
To activate the RadEditor for SharePoint lists for a given site (initially this will activate the tool for Mozilla users only).
STSADM -o activatefeature -id F374A3CA-F4A7-11DB-827C-8DD056D89593 -url [site URL]
To activate the RadEditor for IE users.
Where did we get those ID strings you ask? Look in the “Feature.xml” file in the following locations:
C:Program FilesCommon FilesMicrosoft Sharedweb server extensions12TEMPLATEFEATURESRadEditorFeature
C:Program FilesCommon FilesMicrosoft Sharedweb server extensions12TEMPLATEFEATURESRadEditorFeatureIE
The feature ID is listed in this document between the (big surprise) Id tags.
Now, how to I activate this feature so that it will be on for all future sites? Perhaps the answer is “Feature Stapling”:
After using the Telerik “RadEditor for SharePoint 2007 Lite” for a few months, I decided that we should purchase the full version of the product. A piddly $350 gets you the right to run the full version of this most incredibly useful tool on all of your SharePoint sites. When was the last time that you bought anything for your servers for $350?
If you have not seen RadEditor before, you need to:
I did run into a brief hiccup in installation, though. After installing the software and deploying it as a solution from SharePoint central admin, I found that regular users could not activate the RadEditor feature on their sites. We get the intimidating “403 Forbidden” error…
After a good deal of head pounding, it is SysInternals to the rescue again:
I loaded up ProcMon, set a filter for the SharePoint service accounts, and another filter for Result = “ACCESS DENIED”. Lo and behold, the WSS service account is getting “ACCESS DENIED” to the following files:
C:Program FilesCommon FilesMicrosoft Sharedweb server extensions12TEMPLATECONTROLTEMPLATESRadEditorList.ascx
C:Program FilesCommon FilesMicrosoft Sharedweb server extensions12TEMPLATEFEATURESRadEditorFeatureRadEditorList.ascx
Interestingly, the WSS service account actually does have R/W access to these files. However, recall that the WSS service account actually impersonates the credentials of the user currently logged in to SharePoint. We note in the ProcMon event details the following:
Desired Access: Generic Write, Read Attributes
Options: Sequential Access, Synchronous IO Non-Alert, Non-Directory File
ShareMode: Read, Write
Eureka! The SharePoint end user needs to be able to over-write these files! Sounds a bit shaky from a security perspective, but if we grant the R/W access to these files to all SharePoint users, we find that problems with site feature activation disappear.