Back to Cleverworkarounds mainpage
 

Oct 08 2007

An annotated IPSEC example

Tags: Cisco,IPSEC,Linksys,VPN @ 3:36 pm
Send to Kindle


IPSEC.. WTF? Isn’t this supposed to by SharePoint?

Well, yeah you got me.. but a few years back I was a Cisco nerd in the ISP industry and got pretty handy at it. I wrote this article 3 years ago but then forgot about it until recently.. so it may as well see the light of day because at the time I wrote it, there was very little info out there on this subject.

Continue reading “An annotated IPSEC example”

 Digg  Facebook  StumbleUpon  Technorati  Deli.cio.us  Slashdot  Twitter  Sphinn  Mixx  Google  DZone 

No Tags

Send to Kindle


Oct 08 2007

SharePoint Branding – How CSS works with master pages – Part 1

Send to Kindle

This is version 2 of this article, after I went and accidentally blew away my first masterpiece that took literally days to write. If this has ever happened to you, don’t you hate it, that your second version is never as good as your first?

Quick Links: [Part 1, Part 2, Part 3, Part 4, Part 5, Part 6, Part 7]

Anyway, this is (attempt 2 of) part 1 of a series of articles that cover SharePoint branding in some detail. Kudos has to be given Heather Solomon especially for her wonderful site and articles on this subject (and author of the book to your left :). In Addition, Andrew Connell and Mike have done some great work that helped me in this area.

So, SharePoint branding was the catalyst behind my deciding to make a blog and call it cleverworkarounds. The whole experience at times made me want to change careers, but I ultimately got there. I would go down one path, only to be stumped by a problem, and think I have the solution, only to find another quirk that needed another workaround. So the aim of cleverworkarounds is to determine the least dodgy way to implement branding of a SharePoint installation. No doubt people will disagree with the conclusions I’ve reached, but that’s expected since the cleverness of a workaround really depends on your needs.

 

So this series of articles will cover a few issues. First some basic master page theory, then I will talk about the difference between branding in WSS3 (the freebie version) and MOSS07 (the pricey one). I will then take you through the quirks of CSS and master pages. Subsequent articles will get into the details of branding techniques and finally finish off by covering the governance issues surrounding branding.

Continue reading “SharePoint Branding – How CSS works with master pages – Part 1″

 Digg  Facebook  StumbleUpon  Technorati  Deli.cio.us  Slashdot  Twitter  Sphinn  Mixx  Google  DZone 

No Tags

Send to Kindle


Oct 08 2007

A simple example of a SharePoint “feature”

Send to Kindle


If you check my introductory post, I discussed the concept of SharePoint features in a real world scenario. In this post I actually show an example of features from end to end, to illustrate that scenario.

So, first to recap the scenario, slightly simplified from my other post: A webdesigner has a new CSS file that is the new corporate branding standard. They must package it up as a ‘feature’. A misunderstood sysadmin nazi installs the feature onto the SharePoint farm once only, then sends a mail to the 35 site collection owners advising them to activate the "branding feature" on their sites.  Each site collection owner who does so has the identical configuration modified so it is all nice and consistent.

Now also before we start, this demo requires the "Office SharePoint Server Publishing Infrastructure" feature to be enabled. If this is not enabled, the "Style Library" document library that we rely on, will not exist.

Step 1: Create the Feature

Our web designer of course has a development box so they can’t kill production. On this box they navigate to the

C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES

and create a new folder called CustomBranding

C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\CustomBranding

Inside this folder we place our CSS file (in this case, called CustomBrand.CSS) and we create a file called FEATURE.XML.

Now in real life, you will copy a FEATURE.XML from one of the many other features here and work off that. But in our case, we will just type it in. The contents of FEATURE.XML is this:

<Feature Id="01c34560-6561-11dc-8314-0800200c9a66″   
Title="Pimp my SharePoint"   
Description="This is a feature that adds a new sexy CSS"   
Version="1.0.0.0″   
Scope="Site"   
xmlns="
http://schemas.microsoft.com/sharepoint/">   
<ElementManifests>        
    <ElementManifest Location="ProvisionedFiles.xml"/>   
</ElementManifests>
</Feature>

So we have a <feature> element and inside that an <elementmanifests> element. The required parameters for the <feature> element are below (lifted straight from MSDN)

Attribute Description
Description Optional String. Returns a longer representation of what the Feature does.
Id Required Text. Contains the globally unique identifier (GUID) for the Feature.
Scope Required Text. Can contain one of the following values: Farm (farm), WebApplication (Web application), Site (site collection), Web (Web site).
Title Optional Text. Returns the title of the Feature. Limited to 255 characters.
Version Optional Text. Specifies a System.Version-compliant representation of the version of a Feature. This can be up to four numbers delimited by decimals that represent a version.

So the first thing to do is generate a GUID. You can do this a number of ways, but I typically use an online generator like the one here to do it.

My GUID from the online generator is:  01c34560-6561-11dc-8314-0800200c9a66. Feel free to use it for this example but you should substitute with your own.

Title and description parameters should be plainly obvious and version is optional, but whack it in anyway.

Scope is important, a feature can be activated at various points in the farm. "Site" means it is activated once per site collection. All sub-sites under this site collection can make use of the feature without having to activate it. This will become clear later.

Next we refer to an <element manifest>. This is a reference to another XML file that actually tells Sharepoint what to do (provisionedfiles.xml). In our case, it is going to tell SharePoint to upload the CustomBrand.CSS file to the site collection style library.

Let’s take a look.

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
    <Module Name="MyPimpedStyles" Url="Style Library" RootWebOnly="TRUE">        
        <File Url="CustomBrand.css" Type="GhostableInLibrary" />    
    </Module>
</Elements>

In this file, the top-level Elements element defines the elements comprising the Feature. In my previous post, I outlined a table of elements that can be used to install SharePoint features.

  • Content Types: Contains a definition of a SharePoint content type.
  • Content Type Binding: Actually applies a content type to a document library.
  • Control: Allows you to replace existing controls on the page, such as the search or navigation with your own custom control.
  • Custom Action: You can define custom actions such as add a new menu item in "Site Actions".
  • Feature/Site Template Association: This allows you to bind a feature to a site template so that the feature is included in new sites based on that template.
  • Field: Contains a field, or column definition that can be reused in multiple lists.
  • Hide Custom Action: Opposite to "Custom Action", where you want to hide menu items.
  • List Instance: Provisions a SharePoint site with a list which includes specific data.
  • List Template: A list definition or template, which defines a list that can be provisioned to a SharePoint site.
  • Module: Deploys files which are included when provisioning sites.
  • Receiver: Defines an event handler for a list, or document library
  • Workflow: Defines a workflow for a list, or document library. 

So as you can see in the above XML file, we have used the MODULE element to install 1 single file. Let’s examine the <MODULE> and <FILE> element in detail.

<Module Name="MyPimpedStyles" Url="Style Library" RootWebOnly="TRUE">        
<File Url="CustomBrand.css" Type="GhostableInLibrary" />    
</Module>

Module Attribute Description
Name Required Text. Contains the name of the file set.
RootWebOnly Optional Boolean. TRUE if the files specified in the module are installed only in the top-level Web site of the site collection.
Url Optional Text. Specifies the virtual path of the folder in which to place the files when a site is instantiated. If Path is not specified, the value of Url is used for the physical path. Use the Url attribute to provision a folder through the Feature.
File
Attribute
Description
IgnoreIfAlreadyExists Optional Boolean. TRUE to provision the view even if the file aready exists at the specified URL; otherwise, FALSE.
Type Optional Text. Specifies that the file be cached in memory on the front-end Web server. Possible values include Ghostable and GhostableInLibrary. Both values specify that the file be cached, but GhostableInLibrary specifies that the file be cached as part of a list whose base type is Document Library.When changes are made, for example, to the home page through the UI, only the differences from the original page definition are stored in the database, while default.aspx is cached in memory along with the schema files. The HTML page that is displayed in the browser is constructed through the combined definition resulting from the original definition cached in memory and from changes stored in the database.

So, the module section is specifying where any <file> elements be copied to. We are going to copy this to the document library called "Style Library" in the root web site for the site collection. 

 

Step 2. Installing and testing the Feature

Now that our web developer has created the feature, they test it on their development SharePoint server. Open command prompt and execute the STSADM -installfeature command. When the -name parameter is specified, SharePoint knows to look in the TEMPLTE\FEATUIRES folder already, so you do not have to specify a full path.

Step 3. Test the feature

Okay, so the feature is installed. Now what? Now we need to activate this feature on a site collection. Here is the "Style Library" of my test site. (Remember that this library will not exist unless the SharePoint Publishing Infrastructure feature has been installed). Note that at this time, there is no CSS file called CUSTOMBRAND.CSS

So now let’s Activate the feature. Browse to Site Actions>Site Settings and from the Site Collection Administration menu, choose "Site Collection Features". Lo and behold! We have our feature listed! Note the title and description is as per our FEATURE.XML file.

Click "Activate" to activate the feature (you can also do this on the command line via STSADM -o activatefeature command). Once it is marked as active, re-examine the style library. Woo freakin hoo! There is our CSS file!

Step 5. Test and deploy the Feature

In our example here, we can test this feature, by choosing to use this new CSS file in the master page settings of any site within the site collection. The Site Collection administrator navigates to site settings->look and feel->master page settings and specifies the CSS file override as shown below.

By clicking on the "Browse" button, they can select the CSS file from the style library in the site collection.

This highlights the relationship between the web designer and the farm, site collection and site owners. In a large production farm the sequence would look something like this.

  • The developer creates and tests the feature
  • The developer hands the tested and approved feature to the the SharePoint farm administrator
  • The SharePoint farm administrator copies this feature into the FEATURES folder on the web front end servers on the farm and notifies the site collection administrators that the feature has been installed
  • Each site collection administrator activates the feature and informs the site owners that the feature is now available.
  • Each site owner optinally chooses to use this new CSS installed by the feature.

Summing Up

I hope that you found this article useful. Now you are going to totally hate me, because now I am going to tell you that features are only half of the solution to SharePoint customisation. "What is the other half"? you may ask.  Well the other half of the solution is "solutions" … don’t you just love generic terminology!

 

 

 Digg  Facebook  StumbleUpon  Technorati  Deli.cio.us  Slashdot  Twitter  Sphinn  Mixx  Google  DZone 

No Tags

Send to Kindle


Oct 08 2007

SharePoint “Features” in plain English

Send to Kindle


Features in SharePoint seem to be somewhat misunderstood. Maybe I just deal with too many people who do not seem willing to RTFM (and in the 2007 incarnation of SharePoint, that’s simply asking for trouble).

So.. ‘Features’. Here is the MSDN blurb..

"Microsoft Windows SharePoint Services 3.0 introduces an inherently portable and modular functionality known as a feature, which simplifies modification of sites through site definitions. A feature is a package of Windows SharePoint Services elements that can be activated for a specific scope and that helps users accomplish a particular goal or task".

Clever Workarounds Translation: "Features provide a method to add/customise many areas of SharePoint. "

Wasn’t my explanation so much simpler!

Okay, so what does that mean to me? Well, if you are a SharePoint application developer or a web designer, chances are that if you are customising a SharePoint system in a medium to large scale enterprise, you will find that the usage of features are mandated by those annoying sysadmins and governance nazis who never make anything easy for you.

Here’s your real world example to go with the explanation. We have a cast of characters…

  • Webdesigner: Friendly and completely metrosexual.
  • Sysadmin Nazi: Nerdy, no fashion sense and generally sullen when asked to do something.
  • Site Owners: Non techy staff within various business units who have some administrative responsibility for one or more areas within the SharePoint farm. Opening a web browser and navigating to favourites is considered a technical acheivement.
  • Corporate communications and PR: Determine branding and responsible for marketing related matters. Second only to senior management in terms of being technically inept.

Scenario A:

Our metrosexual webdesigner has cracked out [insert flavour of the month HTML editor here] and customised the SharePoint default page by adding a couple of CSS files with associated style images, perhaps added some flash too. ‘Just upload them to the style library in each site’, they say. Your SharePoint infrastructure manager (hereby known as sysadmin nazi), gets even more bitter and twisted than usual, having to do this task for the 35 sites currently installed on the SharePoint farm. What’s more, they only had a single shot latte that morning and hit the wall early.. so they were inconsistent with the last few sites and missed a few files.

Clever Workaround rating: "weenies"

Now no-one wants to be labeled a weenie, so let’s see if we can make this more clever.

Scenario B:

Aforementioned webdesigner is handed a SharePoint governance document by smug sysadmin nazi who mandates amongst other things, that they must package up all of their files as a ‘feature’. After grumbling about red tape, they finally accept the fact that the sysadmin nazi won’t allow their change into production and they eventually produce a feature folder. Sysadmin nazi installs the feature onto the SharePoint farm once only, then sends a mail to the 35 site owners advising them to activate the "branding feature" on their sites.  Each site owner who does so has the identical configuration modified so it is all nice and consistent.

Clever Workaround rating: "moderately clever"

So in case it’s not obvious, the nice thing about a feature is that once installed by the server/farm administrator, it can be activated by site owners on a case by case basis. Not only can it be activated, it can also be deactivated too. (Some comments with regard to this are in a forthcoming post). The thing to note is the decision to activate/deactivate a feature is made by the site owner, not the farm administrator. So the implication of this is that a feature doesn’t necessarily force change. A company with autonomous divisions may have totally different branding for their sites, and thus would not activate this feature for their sites.

Now let’s talk about updating features once they are installed.

To do this, let’s go back to our branding scenario where now, those arty farty corporate communications and branding dudes decide that the 1 pixel green line is not quite the right green and ask for it to be changed. (They get paid for this – go figure). The web designer (who by now has seen the light and offered some personal hygiene tips to sysadmin nazi) updates the CSS file and creates a new feature file for the sysadmin nazi. Sysadmin nazi installs it to the farm before heading to the vending machine for caffeine sustenance. The site administrators deactivate and then reactivate their feature on their sites at their leisure and the world is a happy place.

Okay, so at this point, let’s dive a little deeper…

To implement a Feature you add a subfolder containing a Feature definition within the Features setup directory. This is most likely located  in

C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES.

Within the subfolder in this directory, you include a Feature.xml file. This is the file that SharePoint looks for when a feature is installed. It includes a GUID (all features are unique via GUID), a title and the scope of the Feature. The scope tells SharePoint whether the Feature will be made available to an entire SharePoint farm, a site collection, or a site. SharePoint uses the Feature.xml file to also identify any supporting files like ASPX pages, dynamic-link libraries (DLLs), images, etc. Using this file, you can add customised components such as new Page Templates, List, Content Types, Web Parts, Workflow and events.

Below is the list of elements that a feature can install.

  1. Content Types: Contains a definition of a SharePoint content type.
  2. Content Type Binding: Actually applies a content type to a document library.
  3. Control: Allows you to replace existing controls on the page, such as the search or navigation with your own custom control.
  4. Custom Action: You can define custom actions such as add a new menu item in "Site Actions".
  5. Feature/Site Template Association: This allows you to bind a feature to a site template so that the feature is included in new sites based on that template.
  6. Field: Contains a field, or column definition that can be reused in multiple lists.
  7. Hide Custom Action: Opposite to "Custom Action", where you want to hide menu items.
  8. List Instance: Provisions a SharePoint site with a list which includes specific data.
  9. List Template: A list definition or template, which defines a list that can be provisioned to a SharePoint site.
  10. Module: Deploys files which are included when provisioning sites. (This is how branding can be deployed via feature).
  11. Receiver: Defines an event handler for a list, or document library.
  12. Workflow: Defines a workflow for a list, or document library. 

Next, I suggest you check my other post. This illustrates the creation and install of a basic feature.  In the meantime, I leave you with this thought for the day (If you have ever watched Jerry Springer, you know what I mean )

So, why did we need to digress into features? Three reasons.

The first one is that as a designer or developer, you will find that in the future people will not accept stuff from you unless it is a feature.

The second one is that as a graduate solutions architect or business development manager, if you use this word, you might just sound like you know what you are talking about during presales meetings.

The third reason is that this notion of features is actually quite fundamental to SharePoint. So much so that the differences between WSS3 and the more fully featured MOSS2007 is that MOSS2007 has features that do not come supplied with the free WSS.

 

 

 Digg  Facebook  StumbleUpon  Technorati  Deli.cio.us  Slashdot  Twitter  Sphinn  Mixx  Google  DZone 

No Tags

Send to Kindle



Today is: Thursday 27 November 2014 |