Ryan McCutchen

I thought I would run through some of the tools that have helped me when branding a MOSS intranet. SharePoint Designer or perhaps better yet Studio can be the primary tool for creating master pages, themes, and page layouts, but your gonna need some help when trying to dig through all the CSS in the core.css file, and all it's crazy inheritance. Combing through the css is a big chunk of your effort when you are starting with the default master or the default or classic theme. Most corporate organizations that I have worked with take the approach of "skinning" the SharePoint default look to match there colors and branding as opposed to starting from the ground up. So odds are your starting with the default look : -(

A couple of prerequisite tips before I get to the tools.....

When creating or modify styles - always, always, always put them in a new stylesheet. If you just update core.css, you will have a lot of pain in your life when your discover some goofy UI thing happening on a page, and you have to comb through the 4,000+ lines of styles in core.

Be cautious of overwriting or adding images directly in the _layouts/Images directory (C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\IMAGES) . If the box has to have MOSS reinstalled or perhaps some obscure patch occurs - you can kiss those image updates goodbye. However, I know that sometimes this is unavoidable....or at least a huge time saver. If your implementing a larger project, then put the images you added or modified in source control, and have a build script that will push the images. This way all the customization can be automatically pushed. OR if is a small implementation, at least document the image changes :- )

So.....oh yeah......The Tools:

IE Developer Toolbar
Certainly the biggest challenge in modifying the UI of MOSS is trying to figure out which style does what...and where is does it. And a good way to discover what MOSS is doing with it's ginormous style sheet is to look at the rendered pages in the site. The IE Developer toolbar will provide 2 great features that will aid in this discovery process. 1. From the menu select 'Find' and 'Select Element by Click' which will allow you to click on any element in the page, and see the class used as well as all of the style attributes. So even if you see the class you modified, but say it is still show a incorrect style value (like color, padding, or whatever) then you know your style is being overwritten somewhere else. 2. As you select an element is also gives you a window with the html of the page that is much easier to comb though than viewing source in Notepad - That way you can crawl up and down the html tags to see what styles are being applied at the div, td, tr, table, etc. and......OK #3 - you can also disable scripts with a click so you can see styles without the hover state kicking in (i.e. - Menus)

CSS Finder Code (courtesy of msdn)
Similar to the IE Developer toolbar, you can throw this snippet into a content editor web part, which will allow you to roll over elements on the page and have the css style show up in a div tag on the screen. It is handy and quick, but will not give you as much information as the IE Developer toolbar. I would click on the link above because this page has a css reference chart that is fairly useful - also see Heather Solomon's CSS Reference to get and idea for some of the major styles.

<script language="jscript">
function ClassInfo()
{
    if (window.event.srcElement.className != null)
    {
        stsclass.innerText = window.event.srcElement.className;
    }
    else
    {
        stsclass.innerText = "";
    }
}
 
window.document.body.onmouseover = ClassInfo;</script>
 
<div style="border-style:solid;border-width:1px; width: 281px; height: 34px; 
position: absolute; left: 286px; top: 41px; z-index:15; padding-left:4px; 
padding-right:4px; padding-top:2px; padding-bottom:2px; background-color:#EEEEF4">
<p id="stsclasstitle"><font face="Tahoma" id="stsclasstitle">Classname: </font>
<font face="Tahoma"id="stsclass">&#xa0;</font>
</p></div>

Just Color Picker
Again another tool for style discovery (are you getting that this is a pain) I will use this little piece of freeware to quickly identify the hex color of an element on a page. Sometimes when you swear up and down that you have changed a color but it just wont show, I will get the hex off the screen, and start start seeing where that color shows up in the various style sheets.

SharePoint Skinner
This is a handy tool when you need to create a down and dirty theme - quickly. I'll admit I have not played with this too much, but it will allow you so change colors and images with a few clicks, and export out a theme. This may also help you get an understanding of what css classes effect what styles, but I find the developer toolbar more efficient for that task.

Features and Deployment
The easiest way to deploy your look and feel to SharePoint is to utilize the Solution Framework MOSS provides. Especially in a farm environment where files need to be pushed to multiple servers. Features are also what I would recommend when including look and feel into site definitions. Many people have posted adding master pages to a Module Element in the ONET file of a site definition, but that will deploy a copy of the master page file to every site provisioned based on your definition. To me, this defeats the point of a template as it can not be globally changed now that you have copies stored in every web. You can create features that utilize receiver classes to programmatically apply a master page or theme when a feature is activated. You can also auto-activate these types of features in a custom site definition. Some good examples of how this is done are here:

Graham Sibley shows how to write a feature that deploys a theme to a site
Paul Papanek Stork shows how to write a feature that apply's a master page to a site. This feature will apply a mater page from the /_catalogs directory at the root of the site collection.

Now that you are writing all these crazy features you may want a way to take some of the legwork out of the process. My friend Rich Finn has created a WSP Project Template for Visual Studio that will create the wsp along with the manifest.xml, and .ddf files for you. It also has deployment and upgrade scripts built in to deploy your look and feel to the portal. There is another one on CodePlex called SharePoint Feature Packager that will also do the trick, but Rich's template has less manual steps to get rolling.

These tools definitely make life easier, but before implementing a portal look and feel, be sure to take all the proper planning steps to ensure that what you are implementing will best suit the long term needs of the business. SharePoint has made a lot of headway in how things can be packaged, deployed, and templated, but there are still a lot of gotchas - you don't want to deploy a look and feel to a ton of pages and later find out something drastic has to change. You may find yourself rebuilding pages manually or basically undergoing a site migration. Each organization needs to consider things like:

Site Definitions vs. Site Templates
Themes vs. Masterpages - one or the other or both
Features and scope of those features
What meta data will be applied in our templates

Carefully document the pros and cons of each of these decisions so that the business can understand the potential impacts of the decisions being made during the design phase of a project.

I was looking for a 64bit version PDF iFilter for a new MOSS implementation, and when I was doing my usual browsing through the blogging community the only references I found was to Foxit's iFilter. Not that the Foxit iFilter is bad, but why buy the milk when you can get the <insert noun> for free.

A client pointed this out to me - Adobe Labs has released software that will allow the 32 bit Adobe iFilter to work on MOSS 2007 x64. It's a bit "hacky", but pretty Easy to setup. My guess is that Adobe was getting a lot of guff for not having this out so they had to throw us a bone in the interim.

http://labs.adobe.com/wiki/index.php/PDF_iFilter_8_-_64-bit_Support

Sometimes I think that my experience with SharePoint 2003 is so burned in my brain that is causes me to dwell on topics that very well could be a null issue in MOSS. The concept I was contemplating this week was the option of separating your WSS team sites into a separate web application. In SPS 2003 this was a very common practice primarily because of the separation of WSS and SPS in the 2003 architecture, but in MOSS that distinction is not as apparent or perhaps necessary. Team Sites can be peppered through out your site collection and live anywhere as opposed to 2003 where they primarily resided under sites. This also opens up a lot of different options from an Information Architecture perspective that I would like to discuss.

One thing that vexed me initially, was that the Microsoft Architecture documentation clearly mentions this practice of separating Team Sites in a deployment scenario, and it is still a very sensible pattern. However, maintaining sites on a separate web app or site collection is not really an out of the box solution in MOSS (like it was in 2003). From a usability standpoint, some things need to be tweaked. I pinged several colleagues and discovered that none of them were separating out team sites in their deployments, which got me wondering about how the viability of this approach. Although, separating team sites into a separate web applications can give you several benefits.

Team sites are more adhoc, and well ..."wild west" style in terms of portal governance. They are usually maintained by the business and not IT, and the business has free reign (to a certain extent) over what they do in their team site. My Sites share this model. Team Sites are also very organic in growth, and in many organizations where IT does not audit or control team sites other than provisioning, can tend to become very large high traffic sites with little IT oversight. Separating team sites into separate web applications and a separate app pool from the portal will minimize the risk of this governance model by having Team Sites on a separate SLA (Service Level Agreement) as well as isolation in IIS if things go bad with team sites. This makes sense from a high level architecture perspective to reduce single points of failure, but the reality is that team sites are the real bread and butter of SharePoint, and end users will be in much more of a crisis if their project site is down as opposed a policy in the document center, news or web content, or even enterprise search. So someone looking at the information architecture needs to do careful analysis on the capacity planning of team sites and how that ranks to the portal. Some organizations will be very thin on the "portal" side of a deployment with the majority of users focused on team collaborations while some could be the reverse.....initially. Most groups when deploying a new portal will focus mainly on the governance, design, and taxonomy of the enterprise portal side because that space is really IT's domain - that is where IT will have the control and the capacity to plan. But even if you are not meeting with every stakeholder in the company to determine their department or team collaboration needs (most teams cannot afford the time that analysis would take), do not under estimate the rate at which team sites will grow in your environment. When looking at this from a system availability or resiliency of the environment, you need to consider the practical side of what SLA's are really required, meaning, what functions are absolutely business critical and where do they reside.

I think a downside of this separation whether teams sites are in a separate web application or just all created under the Site Directory is the taxonomy limitation it can create. Creating a separate space for all collaboration to take place can have its advantages, but it can also create usability issues as users now have multiple choices of where to go, and they may not understand the distinction between a team site and the sub site in the portal. For example, say have a publishing site on the central portal available for the IT department that all employees can access, and you also have a team site that only IT users can access to get content internal to the department. Well say your ticketing system is on the enterprise IT site while your system documentation is on the IT team site. Now IT users have 2 separate places to go to do their job, and these 2 places may have different urls and or navigation paths. Is that necessary? With the right permissions model the IT users could see the all employee content and the internal content in department or project sites from the same site. Obviously if each department is it's own site collection than you can have this properly organized with less manual work, but if that is the case then what would be on this separate Team Sites web application? Most team sites can somehow relate back to a department. Otherwise what are users collaborating on?

I'm not saying that one way here is right or wrong, and each method depends on the specific deployment. I would recommend that during the planning phase their is a good amount of time spent on what collaboration means to the organization, and how that is properly blended into the overall taxonomy. If your deployment is small, set a quota on the parent site collection of 25 - 30 gb, and if it gets to close to the quota, analyze what sites are taking the most resources - and scale out to a separate web application if need be , but be cautious of over-architecting a solution and creating more of work around processes for enterprise search and leveraged metadata if it is not required.

A common failure when running the prescan.exe is the 'Exception while looping through virtual servers.' error. This occurs when you do not have WSS 2.0 Service Pack 2 installed. There are a lot of posts on running prescan and helpful articles on TechNet, but few mention the dependency on Service Pack 2, and many companies who are afraid or have not upgraded for one reason or another will run into this issue, and I think it's worth mentioning. Upgrade to SP2 before attempting to run prescan.

Joel Olsen has a good post on prescan, and does allude to SP2's functionality. He mentions how to extract prescan out of sharepoint.exe (older post), but its easier to download it directly if you have not installed MOSS in an upgrade scenario - see post from Shane Young

When starting services on a MOSS installation you could potentially run into an issue starting the Windows SharePoint Services Search service. If you get an error in the event log stating something about the file name or extension is too long, it is most likely due to the fact that the content database is referencing the FQDN name of the database server. You will see this in the configuration page of the service settings when the content database field looks something like WSS_Search_myserver.my.domain.com. Initially I thought changing it in the settings page at the time of starting the service would fix it, but alas it did not. The server is still being referenced by the FQDN. The easiest way to change this is with the following stsadm script:

stsadm -o renameserver -newservername <server name without fully qualifying> -oldservername <server name with the FQDN>

The service started right up for me after that. As always if this is a production environment....or any you don't want to screw up then do a back up first.

Most of you have probably seen the post on the SharePoint team blog post regarding a sample project plan for a MOSS deployment, but I thought I would point out how valuable this is from a cost planning perspective. I suppose depending on the resources your IT organization has, the IT Architect or consultant may have to create a plan for all the initial costs or technical estimates for a MOSS upgrade or deployment. This document really itemizes all the non-technical aspects of the project as well as the technical efforts. As an architect, I know I tend to focus a plan on all of the technical aspects that are needed for a deployment such as how many servers are we going to need, how much SAN space, how much custom code, etc. I will also include time for your business analysts, project managers, etc, as well as some time for configuration and deployment. But if MOSS is new to you, then those last two usually don't get all the thought that they deserve. I think that happens because the common approach is to deploy MOSS as just a portal, and not consider the value it brings as an overall enterprise platform. For example, how much time will it take to create a document management strategy - creating workflows, and defining content types to truly organize documents in a metadata fashion. How much time will it take to create a Records Retention strategy and Archiving Strategy based on all the different business rules in an organization (which will set the scope for the different libraries and record routes that need to be configured). Will you be creating an enterprise search strategy utilizing MOSS to handle all searching functionality for the organization including searching of file shares or Line of Business applications outside of SharePoint? How many one-off web forms can you kill, and plug into InfoPath forms delivered on the portal? How will you integrate will all the other applications, portals, databases, etc in your organization? How much time will it take to get a consensus from the different divisions in a organization on all those strategies? When an organization is new to MOSS most of these questions could likely be asked by the business towards the tail end of the requirements stage as they start to see the potential of the platform - as opposed to up-front when you are selling your business case to management. These types of efforts, if left unplanned, will usually involve you going back to management to ask for more money and time.

While this document wont really give you a "hand holding" type of experience on all the different tasks involved, it still gives you the ability to strip out a pretty good checklist of all the things you need to cover off on in order to create an up front costing / level of effort plan that will keep you much closer to the actual cost to deploy the MOSS platform to your organization.

The Business Definition Editor is a cool utility that comes with the Office Server 2007 SDK. It allows to you to create an application definition for the BDC in a gui environment, and creates all the xml goo automatically - click here for more

For those you like me who immediately installs an app, and then begins to click wildly hoping for everything to work out should take note that the BDC Definition Editor DOES need to be installed on your web front-end server running SharePoint. Of course this is obvious to some, especially those who take the time to go through the READ ME file before jumping in, but I don't feel like too much of an idiot because I saw several posts on the interwebs of users complaining of issues with the tool, and no one mentioned this obvious fact. So I installed it on my dev box (without MOSS) and quickly discovered that I could not connect an existing web service, but I could get there from my browser.

If the app is installed on a box not running SharePoint, and you attempt to connect to a web service url when clicking Add LOB System,you get - "Error Downloading Web Service". Install the editor on my SharePoint box and life is good. I did see someone suggest that you can copy the wsdl file local, change the connection settings, and it will work, but I cannot verify that.....Just a tidbit for those like me who click first and read later.

When rolling out a portal product to the enterprise, it is so easy for us IT types to drool over all the latest features that a product like MOSS provides. Architects, developers, or whatever usually can look at a set of features - immediately understand it and the potential it can have to the business. When we look at a feature set like the one MOSS provides out of the box it can be overwhelming to think of all the different possibilities - both OOB and from a custom development perspective. But how do you relay that to your business community. So many of us IT folks have such a difficult time being able to think like a non-technical person. We tend to think that by rolling these features out the business, that they will have the same vision of it's potential, flock to it, and revel in all its glory. But that is usually not the case in most environments. Especially those where IT doesn't have a large presence to the overall business strategy. Many IT folks will assume that everyone knows what blogs are, or social networking, IM, etc. But maybe those people never got a call from their Mom needing to fix her computer because she somehow jammed a floppy disk into the CD ROM drive (true story).

Obviously the success on a portal deployment will heavily depend on communication and evangelizing your portal vision from a functional and technical perspective. But who should do that? IT? I know that personally, I have a hard time relaying technical stuff to non-technical people. We techies have a tendency to leave your average business user in a near comatose state as we blaze through all the sexy things that our applications can do. OK....so lets train them right. We'll sit our users down for a 3 day dive into our product. Which is all good and well from an IT project checklist perspective, but the users are walking away with about 5 - 10% understanding of the material that was covered. They will go back to their daily jobs without a second thought to your life changing portal. And then they will someday need to interface with your product as part of their job.....and that's when they call the help desk.

So how do you keep from helping that same old admin post a document for the 10th time? You pass that skill on to key users in your organization - Business Subject Matter Experts. However, this can be difficult given your SMEs will most likely not be techies either. Usually where this goes south is when people are assigned this duty. As part of a project, IT will tell the business to assign a SME within their division. Management will hand this honor down to some poor schlub who will have to take this on as a recreational activity on top of their daily job. So basically this will just create a level of abstraction between IT and the business. So now a user is calling the help desk on behalf of another user. SMEs in the business need support from their management - If management is not supporting these people then it will die on the vine. That's half the battle - the other is that your SMEs actually need to want the job. They need a passion for your product. This is hard to find - it is the Bigfoot of business users. To do this you need to seek out the passion. Look for glimmers of this passion in a business user and capitalize on it. You know you've seen it - Those users who call five times a day with questions....and are ecstatic when they get their issue solved. The users who ask you to recommend a good book for the product. The user who starts asking you when the next version is coming out. When you see this type of behavior, you may have a potential SME on your hands....and if this person is willing to sign up for the job then it is your job to turn this seed into a beautiful flower. Focus on these types of SMEs and your phone will ring less and less. This type of passion for a portal or application distributed to key users in the business will allow your strategic vision to be better realized. Information workers don't want a 10 paragraph email explaining a feature set, or even a long drawn out training class. They want someone 2 cubes down from them who they can ping whenever they hit a wall. With this grass roots or guerilla type training - end users will pick up features at a much quicker rate. Which of course is the lynchpin of any portal project - It can be the greatest technical masterpiece known to man, but will fail without user adoption.