Microsoft Office SharePoint Designer 2007 or Not

SharePoint Designer (SPD) is a nifty tool to use to customize SharePoint sites. It is very powerful and allows us to quickly make style, organizational, functional, and content changes quickly and easily. Today, I ran across a post from Joel Oleseon where he shared his professional opinion in response to another post about the tool from Mark Rackley which was motivated in response to Microsoft’s announcement to make the tool available for free. There really is nothing new about the debate as it deals with the advantages and disadvantages of empowering an end user with all of the power the tool has to offer. It has just resurfaced since the tool will be freely available.

So… if the debate is not new, what’s all the fuss about?

Regardless of the stance that you take about allowing SPD to be used in a production SharePoint deployment or not, the real cause of concern is how SPD can impact production environment when used by untrained/uninformed users with appropriate rights. This reminds me of the quote – with great power comes great responsibility… or something like that. I don’t see the need for huge concern. That is assuming people with those rights have already been trained and informed. For the most part, people with contributor or higher permission role assignments can already do plenty of damage to a production environment with only the web browser at hand. Hence, the need and argument for appropriate training, content approval (and publishing) planning and enforcement, and governance plans (especially in Extranet/Internet facing deployments).

Okay… so what should we do?

There shouldn’t be too much to do (assuming training, content approval, governance, etc. has already been addressed). Professionally, I will be making sure to emphasize the role of SPD in SharePoint projects. I will also make sure to encourage the inclusion or addition of SPD training for existing and new SharePoint users (especially “power” users), administrators, and developers.

Joel Oleson’s Recommendations for SharePoint Application Pool Settings

I have used Joel Oleson’s recommenations to tweak many IIS application pools for countless SharePoint sites. The nice things about his recommendations is that he explains his logic behind them. This lets you decide whether or not to follow each recommendation based on the effect you are trying to acheive.

The PeopleEditor Class and the Visibility Attribute

When doing custom development for MOSS 2007 or WSS 3.0, the PeopleEditor class can come in handy. However, it seems that it begins misbehaving when the the Visibility attribute is changed from its default value of true. Recently, I had the need to make it disappear and reappear depending on certain conditions in a custom form that was developed and I ran into this problem. The work around simply involves using a display style attribute. To make control invisible, set the display style attribute value to none. To make the control visible again, set the display style attribute value back to block.

Here is a sample C# method that I used to make this happen:

private void SetPeopleEditorVisibility(ref PeopleEditor pe, bool visible)
{
  if (pe.Style.Keys.Count > 0 && pe.Style["display"] != null)
  {
    pe.Style.Remove("display");
  }
  if (visible)
  {
    pe.Style.Add("display", "block");
  }
  else
  {
    pe.Style.Add("display", "none");
  }
}

Come See Me at the Orange County SharePoint User Group

Tomorrow, September 17th, I will be speaking at the Orange County SharePoint User Group along with Bob Mixon.

Improving SharePoint Search Relevancy through Scopes
6:30pm – 8:00pm – QuickStart, Irvine, CA

Organizations struggle with delivering information within the scope and context of business users needs.  Understanding scope and contextual search needs can be a daunting task.  However, results can be dramatically improved through careful planning, architecture, design, and development techniques.
 
In this session, you will learn the techniques and best practices required to deliver a SharePoint solution that supports scoping of information.  We will cover appropriate architecture, design, and configuration techniques then dive into development.  Development topics will include an introduction to search syntax options and the key query classes offered in MOSS, and search object model with a demonstration of executing queries with scope information.
So if you are in the area, stop by and say hello!

WSS 3.0 and MOSS 2007 Certification

I often get asked how to get “SharePoint certified”. This is actually an easy question to answer since there are four available SharePoint related MCTS certifications from Microsoft. The certifications are:

Usually, the next question I get is… Which one should I take? This question is a bit harder to answer since the answer depends on the individual goal of certification. Nevertheless, I will try to break it down.

Every person who wants to get “SharePoint certified”  should start with exam 70-631 (WSS 3.0 Configuration). This certification shows that you understand how to install and configure a SharePoint farm, use Central Administration, and use and customize out-of-the-box features such as site templates, lists, libraries, and web parts. From a professional perspective, this exam is the corner stone for all things SharePoint since it ensures that the individual with this certification has the essential knowledge to create out-of-the-box solutions using WSS 3.0. To begin preparing for this exam, I suggest strong familiarity with the WSS 3.0 TechNet library.

The next certification to go for depends on your professional goals. If you are a developer and want to build custom solutions, then take the 70-541 exam (WSS 3.0 Development). If you are not a developer and plan on building out-of-the-box solutions with MOSS 2007, then take the 70-630 exam (MOSS 2007 Configuration). My reasons follow below.

Exam 70-541 (WSS 3.0 Development) certifies general knowledge of custom development and advanced customization of WSS features. This includes knowledge of the programming against the WSS object model and using the collaborative application markup language (aka CAML) to create custom applications, templates, features, definitions, and more. It also demonstrates the ability to package and deploy custom solutions using the WSS solution deployment mechanism. To begin preparing for this exam, I suggest strong familiarity with the WSS 3.0 MSDN library. If you are not a developer, then skip this exam.

Exam 70-630 (MOSS 2007 Configuration) certifies the ability to deploy, maintain, monitor, and administrate operations of MOSS 2007. This includes deploying and managing a Shared Service Provided (SSP), search, business intelligence, business forms, user profiles, my sites, business data catalog, and more. Basically, it’s the same as exam 70-631 but with a focus on the premium out-of-the-box features of MOSS 2007 not included in WSS 3.0. If you want to prepare for this exam, then get familiar with the MOSS 2007 TechNet library.

The last exam is 70-542 (MOSS 2007 Development) is another developer focused exam similar to the 70-541 exam. However, the focus shifts from the WSS object model and features to the MOSS object model and features. This exam assumes that you are comfortable with CAML, the .NET framework, and developing applications with WSS. If you want to prepare for this exam, then get familiar with the MOSS 2007 MSDN library.

Sometimes people also end up asking me if using TechNet and MSDN are enough to prepare for the exams. This totally depends on your experience and your level of familiarity with SharePoint and only you can decide if TechNet and MSDN are enough for you. Rest assured there are lots of good learning resources out there to help you prepare for the exams such as books, classes, and more. If you need helping preparing for an exam and finding classes or other learning resources, then go check out the Microsoft Learning.

Caution When Packaging Themes for SharePoint Products and Technologies

Last month, I wrote up a post about how to package themes in a WSS 3.0 Solution Package (WSP file) for deployment on a SharePoint farm. After playing with this package a bit there was on problem that I encountered that was pretty obvious but I failed to take into consideration. The problem was that the SPTHEMES.XML and the OOB_SPTHEMES.XMLfiles that were packaged were deleted when I retracted and deleted the solution. Afterwards, I began to experience strange behavior with themes in my SharePoint environment.

Why did this happen?

A few months ago, I explained how WSS deploys and retracts solution packages. In that explanation, I explored how the WSS run-time checks the solution manifest of the solution package (WSP file) and removes any files, features, and other solution components from the file system and content databases. This includes both the SPTHEMES.XML and OOB_SPTHEMES.XML files that were specified in the solution manifest of the theme package. Take a look at the bold-ed lines in the manifest excerpt below:

<?xml version=1.0encoding=utf-8 ?>
<Solution xmlns=http://schemas.microsoft.com/sharepoint/
         
DeploymentServerType=ApplicationServer
         
ResetWebServer=TRUE
         
SolutionId=D250636F-0A26-4019-8425-A5232D592C10>
 
<TemplateFiles>
 
<TemplateFile Location=LAYOUTS/1033/SPTHEMES.XML/>
 
<TemplateFile Location=LAYOUTS/1033/OOB_SPTHEMES.XML/>
 
<TemplateFile Location=THEMES/MYNEWTHEME/MYNEWTHEME.INF/>
 
<TemplateFile Location=THEMES/MYNEWTHEME/mossExtension.css/>
 
<TemplateFile Location=THEMES/MYNEWTHEME/theme.css/>
 
<!–Additional images and icons (gif, jpg, png files)
      
can be added here using <TemplateFile> elements –>
 
</TemplateFiles>
</Solution>

So when I retracted my theme solution, both the SPTHEMES.XML and OOB_SPTHEMES.XMLfiles were deleted from the file system and the original SPTHEMES.XML was not restored. Luckly, I had a copy of the themes WSP file from which I extracted the OOB_SPTHEMES.XML file and manually copied back to the 12/LAYOUTS/1033 directory. This resolved the odd theme behavior that my environment was experiencing.

Lesson learned?

If you are going to modify files in the SharePoint HIVE in an unsupported manner (such as was the case with the theme package), make sure you have a back up of the original file system files. Like we did with the OOB_SPTHEMES.XML file and make a note on additional steps, aside from solution retraction and deletion, that need to be taken to restore the file system to it’s original state. This means don’t just test the deployment, but also the retraction process before using this type of solution in a production environment.

Packaging Branding and Themes for Deployment in SharePoint Environments

Last week, a colleague asked me to conduct a presentation for some colleagues to discuss best practices concerning SharePoint branding and themes. The presentation was not meant to teach anyone how to create master pages, page layouts, cascading style sheets, or write web pages, but rather, how to package branding and themes for deployment in SharePoint environments As such, I did my homework and demonstrated some approaches in a two hour virtual meeting last night. The purpose of this post is to recap the approaches and practices and provide a reference to the sample Visual Studio 2008 projects that were generated during the session.

Packaging SharePoint Themes

SharePoint themes are an interesting feature in SharePoint that allow site owners to quickly change the appearance of colors, icons, and images buy injecting an additional style sheet that overrides some of the existing styles found in the core.css style sheet. Creating a custom theme involves a couple of simple steps:

  1. Creating a new folder in the 12/TEMPLATE/THEMES directory
  2. Creating a theme.css file to override the out of the box styles defined in the core.css style sheet in the directory created in the previous step
  3. Creating a mossExtension.css file which is appended to theme.css file to create a the actual style sheet that is actually used when viewing pages in the SharePoint site
  4. Creating a <directory name>.inf file that contains some basic setup information about the theme
  5. Adding all the images and icons referenced in the custom style sheets in step 2 and 3 to the new directory created in step 1
  6. Modifying the SPTHEMES.XML file in the 12/TEMPLATE/LAYOUTS/1033 directory

A word of caution! Modifying the SPTHEMES.XML is not a recommended customization practice since this file maybe overwritten by future SharePoint service packs.

It’s easy enough to take an existing theme directory out of the 12/TEMPLATE/THEMES directory, make a copy of it, rename the directory, rename the INF file, edit the INF, theme.css, and mossExtension.css file to create a new theme. However, this approach is not practical in a production SharePoint farm. The practical approach is to use the WSS solution framework to create our own solution package to deploy the custom theme. For more information, I covered the creation of solution packages (WSP files) in detail in a previous post. Let’s take a quick look at the solution manifest for our theme package:

<?xml version=1.0encoding=utf-8 ?>
<Solution xmlns=http://schemas.microsoft.com/sharepoint/
         
DeploymentServerType=ApplicationServer
         
ResetWebServer=TRUE
         
SolutionId=D250636F-0A26-4019-8425-A5232D592C10>
 
<TemplateFiles>
 
<TemplateFile Location=LAYOUTS/1033/SPTHEMES.XML/>
 
<TemplateFile Location=LAYOUTS/1033/OOB_SPTHEMES.XML/>
 
<TemplateFile Location=THEMES/MYNEWTHEME/MYNEWTHEME.INF/>
 
<TemplateFile Location=THEMES/MYNEWTHEME/mossExtension.css/>
 
<TemplateFile Location=THEMES/MYNEWTHEME/theme.css/>
 
<!– Additional images and icons (gif, jpg, png files)
      
can be added here using <TemplateFile> elements –>
 
</TemplateFiles>
</Solution>

The solution includes a modified SPTHEMES.XML file where we added an element to define the custom theme named MYNEWTHEME. You can also see that we included a copy of the original SPTHEMES.XML file and renamed it OOB_SPTHEMES.XML since it’s always a good idea to have back up copy of the file we modified. Finally, you see the critical MYNEWTHEME.INF, mossExtension.css, and theme.css files. For the sake of brevity, additional image and icon files were excluded on purpose.

The WSP file was then generated using a directive file and the MAKECAB utility (directive files and the MAKECAB utility are also covered in my previous post) and deployed using the STSADM utility.

Packaging Branding

There are many different SharePoint Products and Technologies branding techniques. In the presentation, I demonstrated how quickly and easily we can use a solution to deploy custom style sheets, master pages, and page layouts and how we can use a feature receiver to programmatically apply the branding using the object model. Again for the sake of brevity, the demonstration illustrated how a master page can be deployed and applied. However, a similar approach can be used for page layouts, cascading style sheets, XSL files, image files, and any other branding components and artifacts.

The solution manifest to accomplish our task is relatively basic. Here it is:

<?xml version=1.0encoding=utf-8 ?>
<Solution xmlns=http://schemas.microsoft.com/sharepoint/
         
DeploymentServerType=WebFrontEnd
         
SolutionId=A250636F-0A26-4019-8425-A5232D592C10>
 
<FeatureManifests>
 
<FeatureManifest Location=MyBranding\feature.xml/>
 
</FeatureManifests>
 <Assemblies>
  <Assembly DeploymentTarget=GlobalAssemblyCache
           
Location=CustomThemeFeature.dll />
 
</Assemblies>
</Solution>

As you can see, the solution manifest only includes a feature manifest and an assembly that will be deployed to the GAC. The assembly only contains a custom feature receiver class that programatically applies the custom master page and the custom theme discussed earlier in this post.

Let’s take a look at the feature manifest:

<Feature xmlns=http://schemas.microsoft.com/sharepoint/
        
Id=D250636F-0A26-4019-8425-A5232D592C11
        
Description=My custom master page feature.
        
Title=My Custom Branding
        
ReceiverAssembly=CustomThemeFeature, Version=1.0.0.0, PublicKeyToken=1ff5d2fddf39f61b, Culture=neutral
        
ReceiverClass=CustomThemeFeature.FeatureReceiver
        
Scope=Web>
 <ElementManifests>
 
<ElementManifest Location=elements.xml/>
  <ElementFile Location=mycustom.master/>
 </ElementManifests>
</Feature>

The feature manifest is also pretty simple as it includes one element manifest and one element file. The element file is the custom master page that was created. The element manifest will declare a module that will be used to populate the master page gallery with the custom master page. An important thing to notice here is the ReceiverAssembly and ReceiverClass attributes in the Feature element. These attributes tell the WSS solution framework to use a custom assembly and feature receiver class to handle the feature related events. We will look at the feature receiver class in a bit. First lets take a look the element manifest:

<Elements xmlns=http://schemas.microsoft.com/sharepoint/>
 
<Module Name=MasterPages
         List=116
        
Url=_catalogs/masterpage>
  <File Url=mycustom.master
        Type=GhostableInLibrary />
 </Module>
</Elements>

The element manifest is simploy responsible for populating the master page gallery with the custom master page. If our solution and feature also had custom page layouts, those can be added to the master page gallery by adding File child elements to the Module element. Additionally, we could add more modules to populate the style library with custom style sheets and/or XSL files or add other media files to other SharePoint libraries.

Finally let’s take a look at the custom feature receiver class:

using Microsoft.SharePoint;

namespace CustomThemeFeature {
 public class FeatureReceiver: SPFeatureReceiver
{
 
public override void FeatureActivated(SPFeatureReceiverProperties properties) {
  
SPWeb site = (SPWeb)properties.Feature.Parent;
  
site.MasterUrl = “/_catalogs/masterpage/mycustom.master”;
  
site.CustomMasterUrl = “/_catalogs/masterpage/mycustom.master”;
  
site.ApplyTheme(“MYNEWTHEME”);
  
site.Update();
 
}
 
public override void FeatureDeactivating(SPFeatureReceiverProperties properties) {}
  
public override void FeatureInstalled(SPFeatureReceiverProperties properties) {}
  
public override void FeatureUninstalling(SPFeatureReceiverProperties properties) {}
 
}
}

The class simply takes advantage of the feature activated event and to set the values of the master pages and apply a theme to the SPWeb object where the feature is activated.

Similar to the custom theme discussed earlier in this post, a WSP solution file was created using a directive file and the MAKECAB utility. The solution was then deployed with the STSADM utility. The feature was installed with the STSADM utility as well.