Oct03

Can you really make MOSS look the same as any other website?

One of the most common things I’m asked when talking about SharePoint branding topics is about whether you can make SharePoint look as good as a typical website.  And my response is always “yes, of course you can.”  People normally are happy with the answer and move on to something else, but I’ve always gotten the feeling that everyone felt that I might be looking at the world with SharePoint colored glasses.  The proof is in the pudding though….

The University Of Pennsylvania School Of Nursing came to us a few months back and was in the final stages of implementing their public facing MOSS site.  Their goal was to replace their existing site with a new site running in MOSS to take advantage of all of the WCM functionality.  Their existing site already had a great design that they wanted to keep.  I worked with uber SharePoint branding ninja Randy “The Mossman” Drisgill worked with Eric Stern from U Penn to make sure this project launched in time for the start of the new semester.  Eric and his team had already done some early work with the design but there were still some questions about how to recreate some of the existing functionality in SharePoint.  And to top it all off we had about 3 weeks.  Randy worked his usual magic creating several master pages, layouts, CSS, and did some custom XSLT for some content query web parts.  I worked on creating an information architecture that would display all of their current content in an intuitive SharePointy way.  And Eric, honestly I’m not sure exactly what he did but the guy busted his tail and made sure all the content looked like it was supposed to.  If he ever decides to visit Orlando we owe him a frosty beverage of his choosing.

Here’s a look at the original non-SharePoint site:

 

Here’s the MOSS version of the site:

 

Looks pretty similar doesn’t it?  I bet some of you think we just Photoshopped that pic – for those of you doubters here’s a look at that page in edit mode:

 

If you are interested in checking the site out for yourself take a look at http://www.nursing.upenn.edu.    

Published: Oct-03-08 | 0 Comments | 77 Links to this post

Aug12

Using Add from existing site column (and how to break CQWP!)

One of my clients called me last week and seemed to be a little troubled.  To protect his identity I'll call him Gary. 
 
We've been working together to roll out an internal site for a large company.  We'd setup a number of Team Sites and wanted information from several of these sites to roll up into Product sites using the Content Query Web Part (CQWP).  We had created Site Columns at the site collection level to describe the documents we were uploading and set them as Choice fields.  We setup the CQWPs using the filtering capabilities to only show us documents that met specific criteria (the CQWP can only filter on site columns created at the site collection level). It worked like a charm. and everything rolled up as it should until one day a new requirement was introduced to make it so the same documents from a single Team Site could show for multiple product sites.   Gary changed the site column on the list to a choice field with checkboxes. 
 
This is about when phone rang.  Gary told me that the CQWP didn't seem to work with the checkboxes.  (NOTE: There had been about a month since we initially set these columns up and when the call came in).  I checked it out and he was correct, the CQWP wasn't working.
 
Then it occured to me what was happening.  The site column was originally created at the site collection level to support the filtering of the CQWP.  We then created a document library and added our site column as metadata by clicking "Add from existing site column" -- this basically just makes a copy of the site column to the list.  When Gary went in and changed the choice field to use checkboxes it essentially changed the data type.  The CQWP was trying to apply a filter based on a single value choice field but the actual data in the field in the list was choice w/ checkboxes which caused an error.
 
The bottom line is, if you make a site column at the site collection level don't change it!  You run a big risk of having fields of the same name with different types of data.
 
JR
 
 
Published: Aug-12-08 | 2 Comments | 63 Links to this post

Aug07

Setting Expectations: Forms Based Authentication (FBA) with SharePoint

This is the first in what I'm hoping will be a series of posts focused on giving the full story for different pieces of SharePoint functionality.  SharePoint is a very powerful product with a laundry list of features and functionality.  When planning a project the question comes up as to whether SharePoint can do something, the answer is often viewed as yes or no.  In many cases, the answer should be "it depends on what you expect."
 
A good example of this is the decision to use Forms Based Authentication (FBA) with SharePoint.  Because SharePoint 2007 is built on top of ASP.NET 2.0, developers and admins can use FBA to allow users, who's identity information is stored in SQL (or ADAM another non-AD db), to authenticate to SharePoint. 
 
This is very attractive because many times companies want users who are not in their AD to authenticate to SharePoint.  Most often, I see this used for Internet site or Extranet scenarios.  The option to use FBA opens a lot of possibilities for what you can do with SharePoint.
 
I spend a lot of time in the Microsoft TechNet SharePoint Forums and also often get calls from clients who want to use FBA simply because they want to allow external users to authenticate to SharePoint.  This is one of those times where it is important to set expectations properly. 
 
FBA does provide a mechanism where external users can authenticate to your SharePoint server without having to be in AD, but there are some tradeoffs that I don't see mentioned very often (if ever):
 
1) It is complex to setup and configure.  There's a lot more to it than just flipping a switch
 
2) Management of users isn't the greatest.  There are some 3rd party utilities out there that can help out with this though.  I often install this to help make things easier:
 
3) MOSS cannot crawl web applications using FBA so you'd need to use a dual authentication configuration to ensure that search works.  For more information on that, Andrew Connell has a great post about this:
 
4)  **This is the one I never see anyone bring up** Users who authenticate via FBA do not have the same level of functionality available to them as users who authenticate with a Windows Authentication method.  Essentially the client integration features won't work:
  • Links that start client applications are not visible.
  • Documents are opened in the browser. Documents cannot be opened by client applications.
  • Users cannot edit documents on the site directly from the client applications. However, users can download the document, edit the document locally, and then upload the document.
For more information take a look at "Expected Behavior When Client Integration is disabled" in this link:
 
You can always attempt to use some type of workaround, but the point of this post is to explain that FBA isn't a silver bullet.  Anything can be done given enough time and money, but the goal here is to set expectations and give the whole story. 
 
If you have a situation where you want to give external users access to SharePoint and maybe FBA doesn't sound right for you, consider setting up a separate OU in AD for your external users and set a policy that doesn't allow them to authenticate locally to your domain.  Or you could always spin up a separate AD with a one-way trust.
 
Setting expectations is key to any SharePoint implementation.  Take the time to do proper planning and it will make your life easier and lead to happier end users! 
 
If you'd like to get more information about SharePoint Project Planning, sign up for the class I'm co-authoring with Joel Oleson and Nicola Young for the Ted Pattison Group:  SharePoint Planning and Governance
Published: Aug-07-08 | 3 Comments | 19 Links to this post